Van idee tot implementering: ons wysig die bestaande elliptiese kurwe digitale handtekeningskema sodat dit deterministies is, en op grond daarvan verskaf ons funksies vir die verkryging van pseudo-ewekansige getalle wat binne die blokketting verifieerbaar is.
Idee
In die herfs van 2018 het die Waves-blokketting ingesluit , het die vraag dadelik ontstaan oor die moontlikheid om te bekom wat jy kan vertrou.
Verwarrend oor hierdie vraag, het ek uiteindelik tot die gevolgtrekking gekom: enige blokketting is 'n sel; dit is onmoontlik om 'n betroubare bron van entropie in 'n geslote stelsel te verkry.
Maar ek het steeds van een idee gehou: as gebruikersdata met 'n deterministiese algoritme sal onderteken, dan sal die gebruiker altyd so 'n handtekening met die publieke sleutel kan verifieer, en sal seker wees dat die resulterende waarde uniek is. Die orakel, maak nie saak hoe hard dit wil nie, kan niks verander nie; die algoritme lewer 'n ondubbelsinnige resultaat. In wese teken die gebruiker die resultaat aan, maar weet dit nie totdat die orakel dit publiseer nie. Dit blyk dat u die orakel glad nie kan vertrou nie, maar kyk na die resultaat van sy werk. Dan, in die geval van suksesvolle verifikasie, kan so 'n handtekening as 'n bron van entropie vir 'n pseudorandom getal beskou word.
Die Waves blockchain-platform gebruik 'n handtekeningskema opsie . In hierdie skema bestaan die handtekening uit die waardes R en S, waar R afhang van 'n ewekansige waarde, en S word bereken op grond van die boodskap wat onderteken word, die private sleutel en dieselfde ewekansige nommer as R. Dit blyk dat daar is geen unieke afhanklikheid vir dieselfde nie. Daar is baie geldige handtekeninge vir 'n gebruikerboodskap.
Uiteraard kan so 'n handtekening in sy suiwer vorm nie as 'n bron van pseudo-ewekansige getalle gebruik word nie, aangesien dit nie-deterministies is en dus maklik deur die orakel gemanipuleer kan word.
Maar, soos dit geblyk het, is dit eintlik moontlik om dit deterministies te maak.
Ek het groot hoop gehad , maar nadat ek die hardeware bestudeer het, moes ek hierdie opsie laat vaar. Alhoewel VRF 'n deterministiese weergawe van die handtekening en die bewys daarvan bied, is daar 'n vreemde plek in die algoritme wat 'n swart gat oopmaak vir manipulasie van die orakel. By die berekening van die waarde van k () 'n private sleutel word gebruik, wat vir die gebruiker onbekend bly, wat beteken dat die gebruiker nie die korrektheid van die berekening van k kan verifieer nie, wat beteken dat die orakel enige waarde van k kan gebruik wat dit benodig en terselfdertyd 'n databasis van korrespondensies kan onderhou van k en die getekende data om altyd die korrekte resultaat uit die oogpunt van VRF te kan herbereken. As jy 'n tekening sien wat op VRF gebaseer is sonder om die private sleutel bekend te maak, kan jy slim wees: dui die behoefte aan om óf die sleutel te openbaar, óf dit uit te sluit van die berekening van k, dan sal die private sleutel homself outomaties openbaar wanneer die eerste handtekening verskyn . Oor die algemeen, soos reeds genoem, 'n vreemde skema vir 'n lukrake orakel.
Na 'n bietjie nagedink en die ondersteuning van plaaslike ontleders ingeroep, is die VECRO-werkskema gebore.
VECRO is 'n afkorting vir Verifiable Elliptic Curve Random Oracle, wat in Russies verifieerbare ewekansige orakel op elliptiese kurwes beteken.
Alles blyk redelik eenvoudig te wees; om determinisme te bereik, moet jy die waarde van R regmaak voordat die boodskap wat onderteken moet word, verskyn. As R gepleeg is en deel is van die boodskap wat onderteken word, wat verder verseker dat R gecommit word in die boodskap wat onderteken word, word die waarde van S uniek bepaal deur die gebruiker se boodskap en kan dus gebruik word as 'n bron vir pseudorandom getalle.
In so 'n skema maak dit nie saak hoe R vasgestel word nie, dit bly die verantwoordelikheid van die orakel. Dit is belangrik dat S uniek deur die gebruiker bepaal word, maar die waarde daarvan is onbekend totdat die orakel dit publiseer. Alles wat ons wou hê!
Praat van vaste R, let daarop wanneer verskeie boodskappe onderteken word, openbaar dit die private sleutel uniek in die EdDSA-skema. Dit word uiters belangrik vir die eienaar van die orakel om die moontlikheid uit te skakel om R te hergebruik om verskillende gebruikersboodskappe te teken. Dit wil sê, met enige manipulasie of samespanning sal die orakel altyd die risiko loop om sy private sleutel te verloor.
In totaal moet die orakel gebruikers van twee funksies voorsien: inisialisering, wat die waarde R regmaak, en handtekening, wat die waarde S terugstuur. In hierdie geval is die paar R, S die gewone verifieerbare handtekening van 'n gebruikerboodskap wat 'n vaste waarde R en arbitrêre gebruikerdata.
Daar kan aangevoer word dat hierdie skema vir die blokketting niks meer as gewoon is nie . In wese, ja, dit is sy. Maar daar is verskeie nuanses. Eerstens werk die orakel altyd met dieselfde sleutel in alle bewerkings, dit is byvoorbeeld gerieflik om in kontrakte te gebruik. Tweedens, daar is 'n risiko dat die orakel die private sleutel verloor as dit verkeerd optree, byvoorbeeld, die orakel laat jou toe om monsters van die resultaat te maak, dan is dit genoeg om slegs twee toetse te maak om die private sleutel uit te vind en die volledige toegang tot die beursie. Derdens, 'n handtekening wat inheems op die blokketting verifieerbaar is en 'n bron van willekeurigheid is, is pragtig.
Vir ses maande het die idee van implementering in my kop geprut, totdat uiteindelik motivering in die vorm verskyn het . Met 'n groot toekenning kom groot verantwoordelikheid, so die projek sal daar wees!
Implementering
Dus, in hierdie projek op die Waves-blokketting in versoek-reaksie-modus deur oordragtransaksies tussen die gebruiker en die orakel te gebruik. Terselfdertyd word 'n skrip op die orakelrekening geïnstalleer wat die werk streng beheer in ooreenstemming met die logika hierbo beskryf. Oracle-transaksies word geverifieer en die hele ketting van gebruikersinteraksie word herstel. Al vier transaksies is betrokke by die verifikasie van die finale waarde; die slim kontrak bind hulle saam met 'n streng verifikasiedraad, kontroleer alle waardes stap vir stap en laat geen ruimte vir enige manipulasie nie.
Weereens, om dit opsy te sit en duideliker te maak. Die orakel werk nie net volgens die voorgestelde skema nie. Sy werk word heeltemal beheer op die blokketting-vlak deur die gevestigde . Stap na links en die transaksie sal eenvoudig nie deurgaan nie. Dus, as 'n transaksie by die blokketting ingesluit is, hoef die gebruiker nie eers iets na te gaan nie; honderde netwerknodes het reeds alles vir hom nagegaan.
Tans is daar een VECRO wat op die Waves hoofnet werk (jy kan jou eie bestuur, dit is nie moeilik nie, net ). Die huidige kode loop in PHP (aan , waaroor ).
Om die orakeldiens te gebruik moet jy:
- Maak R reg;
- Stuur ten minste 0.005 golwe na oracle alias init@vecr;
- Ontvang die R-kode in die aanhegselveld in die oordrag van 1 R-vecr-token van die orakel na die gebruiker;
- Kry 'n handtekening;
- Stuur ten minste 0.005 Waves na die oracle alias random@vecr, en MOET ook die voorheen ontvangde R-kode en addisionele gebruikerdata in die aanhegselveld aandui;
- Ontvang die S-kode in die aanhegselveld in die oordrag van 1 S-vecr-token van die orakel na die gebruiker;
- Gebruik S-kode as 'n bron van pseudo-ewekansige getal.
Nuanses van die huidige implementering:
- Golwe wat na die orakel gestuur word, word gebruik as 'n kommissie vir die terugkeertransaksie aan die gebruiker, tot 'n maksimum van 1 Golwe;
- R-kode is die samevoeging van 'n greep van die 'R'-karakter en 'n 32-grepe base58-geënkodeerde R-waarde;
- R-kode in aanhangsel moet eerste wees, gebruikersdata kom na R-kode;
- S-kode is die samevoeging van 'n greep van die karakter 'S' en 'n 32-grepe base58-geënkodeerde waarde van S;
- S is die resultaat van modulo-deling, so jy kan S nie as 'n volle 256-bis pseudo-willekeurige getal gebruik nie (hierdie getal kan as 'n maksimum van 252-bis pseudorandom getal beskou word);
- Die eenvoudigste opsie is om die S-kode-hash as 'n pseudo-ewekansige nommer te gebruik.
Voorbeeld van die ontvangs van S-kode:
- Inisialisering:
- Kry R-kode:
- Besoek die resultaat van R-kode-ondertekening en gebruikersdata "willekeurig":
- S-kode ontvang:
Vanuit 'n tegniese oogpunt is die orakel heeltemal gereed vir werk, jy kan dit veilig gebruik. Uit die oogpunt van gebruik deur die gemiddelde gebruiker is daar 'n gebrek aan 'n gerieflike grafiese koppelvlak; dit sal moet wag.
Ek sal bly wees om vrae te beantwoord en kommentaar te aanvaar, dankie.
Bron: will.com