Fra idé til implementering: vi ændrer det eksisterende elliptiske kurve-digitale signaturskema, så det er deterministisk, og baseret på det leverer vi funktioner til at opnå pseudo-tilfældige tal, der kan verificeres inden for blockchain.
Idea
I efteråret 2018 inkluderede Waves blockchain , opstod straks spørgsmålet om muligheden for at opnå du kan stole på.
Forvirrende over dette spørgsmål kom jeg endelig til den konklusion: enhver blockchain er en celle; det er umuligt at opnå en pålidelig kilde til entropi i et lukket system.
Men jeg kunne stadig godt lide én idé: hvis vil signere brugerdata med en deterministisk algoritme, så vil brugeren altid være i stand til at verificere en sådan signatur ved hjælp af den offentlige nøgle, og vil være sikker på, at den resulterende værdi er unik. Oraklet, uanset hvor hårdt det vil, er ikke i stand til at ændre noget; algoritmen producerer et utvetydigt resultat. Grundlæggende registrerer brugeren resultatet, men ved det ikke, før oraklet udgiver det. Det viser sig, at du slet ikke kan stole på oraklet, men tjek resultatet af dets arbejde. Så, i tilfælde af vellykket verifikation, kan en sådan signatur betragtes som en kilde til entropi for et pseudorandom-nummer.
Waves blockchain-platformen bruger et signaturskema вариант . I dette skema består signaturen af værdierne R og S, hvor R afhænger af en tilfældig værdi, og S beregnes ud fra den besked, der signeres, den private nøgle og det samme tilfældige tal som R. Det viser sig, at der er ingen unik afhængighed for det samme Der er mange gyldige signaturer for en brugermeddelelse.
Det er klart, at en sådan signatur i sin rene form ikke kan bruges som en kilde til pseudo-tilfældige tal, da den er ikke-deterministisk og derfor let kan manipuleres af oraklet.
Men som det viste sig, er det faktisk muligt at gøre det deterministisk.
jeg havde store forhåbninger til , men efter at have studeret hardwaren, måtte jeg opgive denne mulighed. Selvom VRF tilbyder en deterministisk version af signaturen og dens bevis, er der et mærkeligt sted i algoritmen, der åbner et sort hul til manipulation af oraklet. Nemlig når man beregner værdien af k () der bruges en privat nøgle, som forbliver ukendt for brugeren, hvilket betyder, at brugeren ikke kan verificere rigtigheden af beregningen af k, hvilket betyder, at oraklet kan bruge enhver værdi af k, det har brug for, og samtidig opretholde en database med korrespondancer af k og de signerede data for altid at være i stand til at genberegne det korrekte resultat set fra VRFs synspunkt. Hvis du ser en tegning baseret på VRF uden at afsløre den private nøgle, kan du være smart: Angiv behovet for enten at afsløre nøglen, eller udelukke den fra beregningen af k, så vil den private nøgle automatisk afsløre sig selv, når den første signatur vises . Generelt, som allerede nævnt, et mærkeligt skema for et tilfældigt orakel.
Efter lidt omtanke og at have fået støtte fra lokale analytikere, blev VECRO-arbejdsordningen født.
VECRO er en forkortelse for Verifiable Elliptic Curve Random Oracle, som på russisk betyder verificerbart tilfældigt orakel på elliptiske kurver.
Alt viste sig at være ret simpelt; for at opnå determinisme skal du rette værdien af R, før meddelelsen, der skal underskrives, vises. Hvis R er begået og er en del af meddelelsen, der signeres, hvilket yderligere sikrer, at R er begået i meddelelsen, der underskrives, er værdien af S entydigt bestemt af brugerens meddelelse og kan derfor bruges som kilde til pseudorandom-numre.
I et sådant skema er det ligegyldigt, hvordan R er fastgjort; dette forbliver oraklets ansvar. Det er vigtigt, at S er unikt bestemt af brugeren, men dets værdi er ukendt, indtil oraklet udgiver det. Alt, hvad vi ønskede!
Apropos fast R, bemærk det når du signerer forskellige meddelelser, afslører det entydigt den private nøgle i EdDSA-skemaet. Det bliver ekstremt vigtigt for ejeren af oraklet at eliminere muligheden for at genbruge R til at signere forskellige brugerbeskeder. Det vil sige, at oraklet altid risikerer at miste sin private nøgle med enhver manipulation eller samordning.
I alt skal oraklet give brugerne to funktioner: initialisering, som fastsætter værdien R, og signatur, som returnerer værdien S. I dette tilfælde er parret R, S den sædvanlige verificerbare signatur af en brugermeddelelse, der indeholder en fast værdi R og vilkårlige brugerdata.
Det kan argumenteres for, at denne ordning for blockchain ikke er mere end almindelig . I det væsentlige, ja, det er det. Men der er flere nuancer. For det første arbejder oraklet altid med den samme nøgle i alle operationer, for eksempel er dette praktisk at bruge i kontrakter. For det andet er der risiko for, at oraklet mister den private nøgle, hvis den opfører sig forkert, for eksempel giver oraklet dig mulighed for at lave prøver af resultatet, så er det nok kun at lave to tests for at finde ud af den private nøgle og få fuld adgang til tegnebogen. For det tredje er en signatur, der er naturligt verificerbar på blockchain og er en kilde til tilfældighed, smuk.
I seks måneder ulmede ideen om implementering i mit hoved, indtil der endelig dukkede motivation op i formen . Med en stor bevilling følger et stort ansvar, så projektet vil være der!
implementering
Altså i dette projekt på Waves blockchain i request-response-tilstand ved hjælp af overførselstransaktioner mellem brugeren og oraklet. Samtidig installeres et script på oracle-kontoen, der styrer arbejdet strengt i overensstemmelse med logikken beskrevet ovenfor. Oracle-transaktioner verificeres, og hele kæden af brugerinteraktion gendannes. Alle fire transaktioner er involveret i at verificere den endelige værdi; den smarte kontrakt binder dem sammen med en streng verifikationstråd, kontrollerer alle værdier trin for trin og efterlader ikke plads til nogen manipulation.
Endnu en gang for at lægge det til side og gøre det klarere. Oraklet fungerer ikke bare efter den foreslåede ordning. Dets arbejde er fuldstændig kontrolleret på blockchain-niveau af de etablerede . Træd til venstre og transaktionen går simpelthen ikke igennem. Så hvis en transaktion er inkluderet i blockchain, behøver brugeren ikke engang at tjekke noget; hundredvis af netværksknuder har allerede tjekket alt for ham.
I øjeblikket kører der en VECRO på Waves hovednet (du kan køre dit eget, det er ikke svært, bare ). Den aktuelle kode kører i PHP (on , om hvilke ).
For at bruge orakeltjenesten skal du:
- Fix R;
- Send mindst 0.005 Waves til oracle alias init@vecr;
- Modtag R-koden i det vedhæftede felt ved overførsel af 1 R-vecr token fra oraklet til brugeren;
- Få en underskrift;
- Send mindst 0.005 Waves til oracle-aliasset random@vecr, og SKAL også angive den tidligere modtagne R-kode og yderligere brugerdata i det vedhæftede felt;
- Modtag S-koden i det vedhæftede felt ved overførsel af 1 S-vecr-token fra oraklet til brugeren;
- Brug S-kode som en kilde til pseudo-tilfældige tal.
Nuancer af den nuværende implementering:
- Bølger, der sendes til oraklet, bruges som kommission for returtransaktionen til brugeren, op til et maksimum på 1 bølger;
- R-kode er sammenkædningen af en byte med "R"-tegnet og en 32-byte base58-kodet R-værdi;
- R-kode i vedhæftet fil skal være først, brugerdata kommer efter R-kode;
- S-kode er sammenkædningen af en byte af tegnet 'S' og en 32-byte base58-kodet værdi af S;
- S er resultatet af modulo division, så du kan ikke bruge S som et fuldt 256-bit pseudorandomtal (dette tal kan maksimalt betragtes som 252-bit pseudorandomtal);
- Den enkleste mulighed er at bruge S-kodehashen som et pseudo-tilfældigt tal.
Eksempel på modtagelse af S-kode:
- Initialisering:
- Få R-kode:
- Forespørgsel efter resultatet af R-kodesignering og brugerdata "tilfældig":
- Modtagelse af S-kode:
Fra et teknisk synspunkt er oraklet helt klar til arbejde, du kan trygt bruge det. Fra den gennemsnitlige brugers brugssynspunkt er der mangel på en praktisk grafisk grænseflade; dette må vente.
Jeg vil med glæde besvare spørgsmål og acceptere kommentarer, tak.
Kilde: www.habr.com