Fra idé til implementering: vi modifiserer den eksisterende elliptiske kurven for digital signatur slik at den er deterministisk, og basert på den gir vi funksjoner for å oppnå pseudo-tilfeldige tall som kan verifiseres i blokkjeden.
Idé
Høsten 2018 inkluderte Waves-blokkjeden , oppsto spørsmålet umiddelbart om muligheten for å få du kan stole på.
Forvirrende over dette spørsmålet kom jeg til slutt til konklusjonen: enhver blokkjede er en celle; det er umulig å få en pålitelig kilde til entropi i et lukket system.
Men jeg likte fortsatt én idé: hvis vil signere brukerdata med en deterministisk algoritme, så vil brukeren alltid kunne verifisere en slik signatur ved hjelp av den offentlige nøkkelen, og vil være sikker på at den resulterende verdien er unik. Oraklet, uansett hvor hardt det vil, er ikke i stand til å endre noe; algoritmen gir et entydig resultat. I hovedsak registrerer brukeren resultatet, men vet det ikke før oraklet publiserer det. Det viser seg at du ikke kan stole på oraklet i det hele tatt, men sjekk resultatet av arbeidet. Så, i tilfelle vellykket verifisering, kan en slik signatur betraktes som en kilde til entropi for et pseudorandomnummer.
Waves blockchain-plattformen bruker et signaturskjema вариант . I dette opplegget består signaturen av verdiene R og S, der R avhenger av en tilfeldig verdi, og S beregnes basert på meldingen som signeres, den private nøkkelen og det samme tilfeldige tallet som R. Det viser seg at det er ingen unik avhengighet for det samme Det er mange gyldige signaturer for en brukermelding.
Åpenbart, i sin rene form, kan en slik signatur ikke brukes som en kilde til pseudo-tilfeldige tall, siden den er ikke-deterministisk og derfor lett kan manipuleres av oraklet.
Men, som det viste seg, er det faktisk mulig å gjøre det deterministisk.
Jeg hadde store forhåpninger til , men etter å ha studert maskinvaren, måtte jeg forlate dette alternativet. Selv om VRF tilbyr en deterministisk versjon av signaturen og dens bevis, er det et merkelig sted i algoritmen som åpner et svart hull for manipulering av oraklet. Nemlig når du beregner verdien av k () brukes en privat nøkkel, som forblir ukjent for brukeren, noe som betyr at brukeren ikke kan bekrefte riktigheten av beregningen av k, noe som betyr at oraklet kan bruke hvilken som helst verdi av k det trenger og samtidig opprettholde en database med korrespondanser av k og signerte data for alltid å kunne rekalkulere resultatet som er korrekt sett fra VRFs synspunkt . Hvis du ser en tegning basert på VRF uten å avsløre den private nøkkelen, kan du være smart: angi behovet for enten å avsløre nøkkelen, eller ekskludere den fra beregningen av k, så vil den private nøkkelen automatisk bli avslørt når den første signaturen vises . Generelt, som allerede nevnt, et merkelig opplegg for et tilfeldig orakel.
Etter litt omtanke og å få støtte fra lokale analytikere, ble VECRO-arbeidsordningen født.
VECRO er en forkortelse for Verifiable Elliptic Curve Random Oracle, som på russisk betyr verifiserbart tilfeldig orakel på elliptiske kurver.
Alt viste seg å være ganske enkelt; for å oppnå determinisme, må du fikse verdien av R før meldingen som skal signeres vises. Hvis R er committed og er en del av meldingen som signeres, noe som videre sikrer at R er committed i meldingen som signeres, er verdien til S unikt bestemt av brukerens melding og kan derfor brukes som kilde for pseudorandom-nummer.
I et slikt opplegg spiller det ingen rolle hvordan R er fikset; dette forblir oraklets ansvar. Det er viktig at S er unikt bestemt av brukeren, men verdien er ukjent før oraklet publiserer den. Alt vi ønsket oss!
Apropos fast R, merk det når du signerer ulike meldinger, avslører det unikt den private nøkkelen i EdDSA-ordningen. Det blir ekstremt viktig for eieren av oraklet å eliminere muligheten for å gjenbruke R for å signere forskjellige brukermeldinger. Det vil si at med enhver manipulasjon eller samarbeid vil oraklet alltid risikere å miste sin private nøkkel.
Totalt må oraklet gi brukere to funksjoner: initialisering, som fikser verdien R, og signatur, som returnerer verdien S. I dette tilfellet er paret R, S den vanlige verifiserbare signaturen til en brukermelding som inneholder en fast verdi R og vilkårlige brukerdata.
Det kan hevdes at denne ordningen for blokkjeden ikke er noe mer enn vanlig . I hovedsak, ja, det er henne. Men det er flere nyanser. For det første jobber oraklet alltid med samme nøkkel i alle operasjoner, for eksempel er dette praktisk å bruke i kontrakter. For det andre er det en risiko for at oraklet mister den private nøkkelen hvis den oppfører seg feil, for eksempel lar oraklet deg ta prøver av resultatet, da er det nok å gjøre bare to tester for å finne ut den private nøkkelen og få full tilgang til lommeboken. For det tredje er en signatur som er naturlig verifiserbar på blokkjeden og er en kilde til tilfeldighet vakker.
I seks måneder ulmet ideen om implementering i hodet mitt, helt til det endelig dukket opp motivasjon i formen . Med et stort tilskudd følger stort ansvar, så prosjektet vil være der!
implementering
Så i dette prosjektet på Waves-blokkjeden i forespørsel-svar-modus ved å bruke overføringstransaksjoner mellom brukeren og oraklet. Samtidig installeres et script på oracle-kontoen som kontrollerer arbeidet strengt i samsvar med logikken beskrevet ovenfor. Oracle-transaksjoner blir verifisert og hele kjeden av brukerinteraksjon gjenopprettes. Alle de fire transaksjonene er involvert i å verifisere den endelige verdien; den smarte kontrakten setter dem sammen med en streng verifiseringstråd, sjekker alle verdier trinn for trinn og gir ikke rom for noen manipulasjon.
Nok en gang, for å legge det til side og gjøre det klarere. Oraklet fungerer ikke bare etter den foreslåtte ordningen. Arbeidet er fullstendig kontrollert på blokkjedenivå av de etablerte . Gå til venstre og transaksjonen går rett og slett ikke gjennom. Så hvis en transaksjon er inkludert i blokkjeden, trenger ikke brukeren engang å sjekke noe; hundrevis av nettverksnoder har allerede sjekket alt for ham.
For øyeblikket er det én VECRO som kjører på Waves hovednett (du kan kjøre ditt eget, det er ikke vanskelig, bare ). Den nåværende koden kjører i PHP (på , om hvilken ).
For å bruke orakeltjenesten må du:
- Fix R;
- Send minst 0.005 Waves til oracle alias init@vecr;
- Motta R-koden i vedleggsfeltet ved overføring av 1 R-vecr-token fra oraklet til brukeren;
- Få en signatur;
- Send minst 0.005 Waves til oracle-aliaset random@vecr, og MÅ også angi den tidligere mottatte R-koden og tilleggsbrukerdata i vedleggsfeltet;
- Motta S-koden i vedleggsfeltet ved overføring av 1 S-vecr-token fra oraklet til brukeren;
- Bruk S-kode som en kilde til pseudo-tilfeldig tall.
Nyanser av gjeldende implementering:
- Bølger som sendes til oraklet brukes som en provisjon for returtransaksjonen til brukeren, opptil maksimalt 1 bølger;
- R-kode er sammenkoblingen av en byte med 'R'-tegnet og en 32-byte base58-kodet R-verdi;
- R-kode i vedlegg skal være først, brukerdata kommer etter R-kode;
- S-kode er sammenkoblingen av en byte med tegnet 'S' og en 32-byte base58-kodet verdi av S;
- S er resultatet av modulo-divisjon, så du kan ikke bruke S som et fullt 256-bits pseudorandomtall (dette tallet kan betraktes som et maksimum på 252-biters pseudorandomtall);
- Det enkleste alternativet er å bruke S-kodehashen som et pseudo-tilfeldig tall.
Eksempel på mottak av S-kode:
- Initialisering:
- Få R-kode:
- Spørre resultatet av R-kodesignering og brukerdata "tilfeldig":
- Mottar S-kode:
Fra et teknisk synspunkt er oraklet helt klart for arbeid, du kan trygt bruke det. Fra den gjennomsnittlige brukerens synspunkt mangler det et praktisk grafisk grensesnitt; dette må vente.
Jeg vil gjerne svare på spørsmål og godta kommentarer, takk.
Kilde: www.habr.com