Od ideje do izvedbe: obstoječo shemo digitalnega podpisovanja eliptične krivulje spremenimo tako, da je deterministična in na njeni podlagi zagotovimo funkcije za pridobivanje psevdo-naključnih števil, preverljivih znotraj blockchaina.
Ideja
Jeseni 2018 vključena veriga blokov Waves , se je takoj porajalo vprašanje o možnosti pridobitve lahko zaupate.
Ko sem razmišljal o tem vprašanju, sem končno prišel do zaključka: vsaka veriga blokov je celica; v zaprtem sistemu je nemogoče pridobiti zaupanja vreden vir entropije.
Ena ideja mi je bila vseeno všeč: če bo uporabniške podatke podpisal z determinističnim algoritmom, potem bo lahko uporabnik takšen podpis vedno preveril z javnim ključem in bo prepričan, da je nastala vrednost unikatna. Orakelj, ne glede na to, kako močno želi, ne more ničesar spremeniti, algoritem daje nedvoumen rezultat. V bistvu uporabnik zabeleži rezultat, vendar ga ne ve, dokler ga orakelj ne objavi. Izkazalo se je, da oraklju sploh ne morete zaupati, ampak preverite rezultat njegovega dela. Potem se lahko v primeru uspešnega preverjanja takšen podpis šteje za vir entropije za psevdonaključno število.
Platforma veriženja blokov Waves uporablja shemo podpisa možnost . V tej shemi je podpis sestavljen iz vrednosti R in S, kjer je R odvisen od naključne vrednosti, S pa se izračuna na podlagi sporočila, ki se podpisuje, zasebnega ključa in istega naključnega števila kot R. Izkazalo se je, da za isto ni edinstvene odvisnosti. Za uporabniško sporočilo je veliko veljavnih podpisov.
Očitno je, da takšnega podpisa v svoji čisti obliki ni mogoče uporabiti kot vir psevdo-naključnih števil, saj je nedeterminističen in ga lahko zato orakelj zlahka manipulira.
Toda, kot se je izkazalo, ga je dejansko mogoče narediti determinističnega.
Imel sem veliko upov , vendar sem moral po študiju strojne opreme to možnost opustiti. Čeprav VRF ponuja deterministično različico podpisa in njegovega dokaza, obstaja nenavadno mesto v algoritmu, ki odpira črno luknjo za manipulacijo oraklja. Namreč pri izračunu vrednosti k () uporabljen je zasebni ključ, ki ostane uporabniku neznan, kar pomeni, da uporabnik ne more preveriti pravilnosti izračuna k, kar pomeni, da orakelj lahko uporabi katerokoli vrednost k, ki jo potrebuje, in hkrati vzdržuje bazo korespondenc. k in podpisanih podatkov, da lahko vedno znova izračunamo pravilen rezultat z vidika VRF. Če vidite risbo, ki temelji na VRF brez razkritja zasebnega ključa, ste lahko pametni: označite potrebo po razkritju ključa ali pa ga izključite iz izračuna k, potem se bo zasebni ključ samodejno razkril, ko se pojavi prvi podpis. . Na splošno, kot že omenjeno, čudna shema za naključni orakelj.
Po kratkem premisleku in podpori lokalnih analitikov se je rodila delovna shema VECRO.
VECRO je okrajšava za Verifiable Elliptic Curve Random Oracle, kar v ruščini pomeni preverljivi naključni orakel na eliptičnih krivuljah.
Izkazalo se je, da je vse precej preprosto; da bi dosegli determinizem, morate popraviti vrednost R, preden se prikaže sporočilo, ki ga želite podpisati. Če je R potrjen in je del sporočila, ki se podpisuje, kar dodatno zagotavlja, da je R potrjen v sporočilu, ki se podpisuje, je vrednost S enolično določena z uporabnikovim sporočilom in se zato lahko uporabi kot vir za psevdonaključna števila.
V taki shemi ni pomembno, kako je R fiksiran; to ostaja odgovornost orakulja. Pomembno je, da S enolično določi uporabnik, vendar njegova vrednost ni znana, dokler je orakelj ne objavi. Vse, kar smo želeli!
Ko že govorimo o fiksnem R, upoštevajte to pri podpisovanju različnih sporočil unikatno razkriva zasebni ključ v shemi EdDSA. Za lastnika orakula postane izjemno pomembno, da odpravi možnost ponovne uporabe R za podpisovanje različnih uporabniških sporočil. To pomeni, da bo orakelj ob kakršni koli manipulaciji ali dogovarjanju vedno tvegal izgubo zasebnega ključa.
Skupaj mora orakelj uporabnikom zagotoviti dve funkciji: inicializacijo, ki popravi vrednost R, in podpis, ki vrne vrednost S. V tem primeru je par R, S običajen preverljivi podpis uporabniškega sporočila, ki vsebuje fiksno vrednost R in poljubni uporabniški podatki.
Lahko trdimo, da ta shema za blockchain ni nič drugega kot običajna . V bistvu ja, to je to. Vendar obstaja več odtenkov. Prvič, orakelj vedno deluje z istim ključem v vseh operacijah, na primer, to je priročno za uporabo v pogodbah. Drugič, obstaja tveganje, da orakelj izgubi zasebni ključ, če se obnaša nepravilno, na primer, orakelj vam dovoli, da naredite vzorce rezultata, potem je dovolj, da naredite samo dva testa, da ugotovite zasebni ključ in pridobite poln dostop do denarnice. Tretjič, podpis, ki je izvorno preverljiv v verigi blokov in je vir naključnosti, je čudovit.
Šest mesecev je ideja o izvedbi tlela v moji glavi, dokler se končno v obrazcu ni pojavila motivacija . Velika nepovratna sredstva prinašajo veliko odgovornost, zato bo projekt tam!
Реализация
Torej, v tem projektu na verigi blokov Waves v načinu zahteva-odgovor z uporabo prenosnih transakcij med uporabnikom in orakljem. Istočasno je na račun Oracle nameščen skript, ki nadzira delo strogo v skladu z zgoraj opisano logiko. Transakcije Oracle so preverjene in celotna veriga uporabniške interakcije je obnovljena. Pri preverjanju končne vrednosti sodelujejo vse štiri transakcije, ki jih pametna pogodba povezuje s strogo verifikacijsko nitjo, tako da korak za korakom preverja vse vrednosti in ne pušča prostora za kakršne koli manipulacije.
Še enkrat, da odložim in naredim bolj jasno. Orakelj ne deluje le po predlagani shemi. Njegovo delo je na ravni blockchaina popolnoma nadzorovano s strani uveljavljenih . Stopite v levo in transakcija preprosto ne bo potekala. Torej, če je transakcija vključena v blockchain, uporabniku sploh ni treba ničesar preverjati, na stotine omrežnih vozlišč je že preverilo vse namesto njega.
Trenutno se na glavnem omrežju Waves izvaja en VECRO (lahko poženete svojega, ni težko, samo ). Trenutna koda se izvaja v PHP (on , o katerem ).
Če želite uporabljati storitev Oracle, morate:
- Popravi R;
- Pošlji vsaj 0.005 valov oracle alias init@vecr;
- Prejmite kodo R v polje za prilogo pri prenosu 1 žetona R-vecr od Oracle do uporabnika;
- Pridobite podpis;
- Pošljite vsaj 0.005 valov na vzdevek Oracle random@vecr in MORATE navesti predhodno prejeto R-kodo in dodatne uporabniške podatke v polju za prilogo;
- Prejmite kodo S v polje za prilogo pri prenosu 1 žetona S-vecr od Oracle do uporabnika;
- Uporabite kodo S kot vir psevdo-naključnega števila.
Nianse trenutne izvedbe:
- Valovi, poslani oraklju, se uporabijo kot provizija za transakcijo vračila uporabniku, do največ 1 valov;
- R-koda je veriženje bajta znaka 'R' in 32-bajtne vrednosti R, kodirane z base58;
- R-koda v priponki mora biti prva, uporabniški podatki so za R-kodo;
- S-koda je veriženje bajta znaka 'S' in 32-bajtne vrednosti S, kodirane z base58;
- S je rezultat modulnega deljenja, zato S ne morete uporabiti kot polno 256-bitno psevdonaključno število (to število se lahko šteje za največ 252-bitno psevdonaključno število);
- Najenostavnejša možnost je uporaba zgoščene kode S kot psevdonaključnega števila.
Primer prejema S-kode:
- Inicializacija:
- Pridobivanje kode R:
- Poizvedba po rezultatu podpisovanja R-kode in uporabniških podatkov »naključno«:
- Prejemanje kode S:
S tehničnega vidika je orakelj popolnoma pripravljen za delo, lahko ga varno uporabljate. Z vidika uporabe s strani povprečnega uporabnika primanjkuje priročnega grafičnega vmesnika, na to bo treba počakati.
Z veseljem bom odgovoril na vprašanja in sprejel komentarje, hvala.
Vir: www.habr.com