Fra idé til implementering: vi modificerer den eksisterende skema for digital underskrift baseret på elliptiske kurver, så den bliver deterministisk, og tilbyder funktioner til at generere verificerbare pseudotilfældige tal baseret på den.

Idé

I efteråret 2018 blev der aktivere de første smart contracts i Waves blockchain , hvilket straks rejste spørgsmålet om muligheden for at opnåpseudotilfældige tal , som man kan stole på.Da jeg tænkte over dette spørgsmål, kom jeg endelig frem til konklusionen: enhver blockchain er en fængsel, det er umuligt at få en pålidelig kilde til entropi i et lukket system.

Men der var ideen, jeg kunne lide: hvis en

tilfældig oracle signerer brugerdata med et deterministisk algoritme, så kan brugeren altid både verificere en sådan underskrift ved hjælp af den offentlige nøgle og være sikker på, at den opnåede værdi er unik. Oracle kan ikke ændre noget, algoritmen giver et entydigt resultat. I bund og grund fastsætter brugeren resultatet, men ved det ikke, før oraklet offentliggør det. Det viser sig, at man slet ikke behøver at stole på oraklet, men blot verificere resultatet af dets arbejde. Så i tilfælde af en vellykket verifikation kan en sådan underskrift betragtes som en kilde til entropi for det pseudotilfældige tal. Waves blockchain-platformen bruger en signaturordning

EdDSA . I denne ordning består en signatur af værdierne R og S, hvor R afhænger af et tilfældigt tal, og S beregnes på baggrund af den signerede besked, den private nøgle og det samme tilfældige tal som R. Det betyder, at der ikke er nogen entydig afhængighed, for den samme brugerbesked findes der mange gyldige signaturer. variant Ed25519Det er tydeligt, at en ren version af en sådan signatur ikke kan bruges som kilde til pseudotilfældige tal, da den er nondeterministisk og således let kan manipuleres af oraklet.

Men som det viste sig, er det faktisk muligt at gøre den deterministisk.

Jeg havde store forhåbninger til

verificerbare tilfældige funktioner (VRF) en verificerbar tilfældig funktion (VRF), men efter at have studeret materialet måtte vi opgive denne mulighed. Selvom VRF tilbyder en deterministisk metode til underskrift og dens bevis, er der et underligt sted i algoritmen, der åbner en sort hul for manipulationer af oraklet. Specifikt, når værdien k beregnes (afsnit 5.1), bruges en hemmelig nøgle, som forbliver ukendt for brugeren, hvilket betyder, at brugeren ikke kan verificere korrektheden af beregningen af k, derfor kan oraklet bruge enhver værdi for k, det ønsker, og samtidig føre en database med forbindelser mellem k og de data, der underskrives, for altid at være i stand til at genberegne et korrekt resultat set fra VRF’s synspunkt. Ser du et VRF-baseret lotteri uden at offentliggøre den hemmelige nøgle, kan du komme med en bemærkning: påpege nødvendigheden af enten at offentliggøre nøgle eller udelade den fra beregningen af k, så vil nøglen automatisk blive afsløret ved den første underskrift. Generelt, som allerede nævnt, en underlig ordning for et tilfældigt orakel.

Efter lidt overvejelse og med støtte fra lokale analytikere blev der udviklet en arbejdsordning for VECRO.

VECRO er en forkortelse for Verifiable Elliptic Curve Random Oracle, som på dansk betyder verificerbar tilfældig orakel på elliptiske kurver.

Det viste sig at være ret simpelt, for at opnå determinisme kræves det, at værdien R fastsættes inden den underskrevne besked optræder. Hvis R er fastsat og er en del af den underskrevne besked, hvilket yderligere sikrer, at R er fastsat i selve den underskrevne besked, så bestemmes værdien S entydigt af brugermeddelelsen og kan derfor anvendes som kilde til pseudotilfældige tal.

I en sådan ordning er det ligegyldigt, hvordan R fastsættes, det forbliver oraklets ansvar. Det vigtige er, at S entydigt defineres af brugeren, men dens værdi er ukendt, indtil oraklet offentliggør den. Præcis som vi ønskede!

Når vi taler om det fastsatte R, så bemærk, at genbrugt R Når man signer forskellige meddelelser, afslører det entydigt den private nøgle i EdDSA-skemaet. For ejeren af oraklet bliver det ekstremt vigtigt at udelukke muligheden for genbrug af R til at signere forskellige brugerbeskeder. Det vil sige, at uanset hvad der sker, vil oraklet altid risikere at miste sin private nøgle.

Alt i alt skal oraklet tilbyde brugerne to funktioner: initialisering, der fastsætter værdien R, og signatur, der returnerer værdien S. Her er parret R, S en almindelig verificerbar signatur på et brugerbesked, der indeholder den faste værdi R og brugerens vilkårlige data.

Man kan indvende, at dette skema til blockchain ikke er andet end et almindeligt commit-reveal skema.I bund og grund ja, det er det. Men der er nogle nuancer. For det første arbejder oraklet altid med den samme nøgle i alle operationer, hvilket gør det praktisk at bruge i kontrakter. For det andet er der risiko for, at oraklet mister den private nøgle ved forkert adfærd, for eksempel hvis oraklet tillader at tage prøver af resultatet; så er det nok at tage to prøver for at finde den private nøgle og få fuld adgang til tegnebogen. For det tredje er en indbygget verificerbar signatur på blockchain, der er kilden til tilfældighed — det er flot.

I et halvt år maturede idéen om implementeringen i mit hoved, indtil motivet endelig dukkede op i form af et legat fra Waves Labs.Med et stort legat følger et stort ansvar, så projektet skal føres ud i livet!

Implementering

Så i dette projekt blev VECRO implementeret på Waves blockchain i en request-response mode ved hjælp af overførsels transaktioner mellem brugeren og oraklet. På oraklets konto er der installeret et script, der kontrollerer driften strengt i overensstemmelse med den ovenfor beskrevne logik. Oraklets transaktioner gennemgår verifikation med genoprettelse af hele kæden af interaktioner med brugeren. Alle fire transaktioner deltager i verificeringen af den endelige værdi; smartkontrakten snører dem på en streng kontroltråd, trin for trin verificerer den alle værdier og efterlader ikke plads til manipulation.

Endnu en gang, for at det kan sive ind og blive klarere. Oraklet fungerer ikke bare efter det foreslåede skema. Dets arbejde kontrolleres fuldstændigt på blockchain-niveau af den installerede fastgjort med en smart kontrakt. Ét skridt til venstre, og transaktionen vil simpelthen ikke gå igennem. Så hvis transaktionen er blevet registreret på blockchain, behøver brugeren ikke engang at tjekke noget, det er allerede blevet verificeret af hundrede noder i netværket.

I øjeblikket er der en VECRO lanceret i Waves hovednetværk (du kan også starte din egen, det er ikke svært, bare se på eksemplet på konfiguration). Den nuværende kode kører på PHP (på WavesKit, som jeg har nævnt tidligere For at bruge orakeltjenesten er det nødvendigt at:).

Fastlægge R;

Sende minimum 0.005 Waves til oraklets alias init@vecr;
- Modtage R-kode i feltet attachment i overførslen af 1 R-vecr token fra oraklet til brugeren;
- Modtage en signatur;
Sende minimum 0.005 Waves til oraklets alias random@vecr, og sørge for at angive den tidligere modtagne R-kode i attachment-feltet samt yderligere brugerdata;
- Modtage S-kode i feltet attachment i overførslen af 1 S-vecr token fra oraklet til brugeren;
- Brug S-koden som kilde til pseudo-tilfældige tal.
Nuancer i den nuværende implementering:

De Waves, der sendes til oraklet, bruges som gebyr for den tilbagevendende transaktion til brugeren, op til maksimalt 1 Waves;

R-kode er en sammenkobling af byte-tegnet ‘R’ og 32-byte værdien R i base58 kodning;
R-koden i attachment skal være først, brugerdata følger efter R-koden;
S-kode er en sammenkobling af byte-tegnet ‘S’ og 32-byte værdien S i base58 kodning;
S er resultatet af division modulo, derfor kan S ikke bruges som et fuldt 256-bit pseudo-tilfældigt tal (dette tal kan betragtes som maksimalt 252-bit pseudo-tilfældigt tal);
Den nemmeste mulighed er at bruge hash af S-koden som pseudo-tilfældigt tal.
Eksempel på modtagelse af S-kode:

Initialization: