Från idé till genomförande: vi modifierar det befintliga systemet för digitala signaturer baserat på elliptiska kurvor så att det blir deterministic, och erbjuder funktioner för att generera verifierbara pseudorandomnummer baserade på detta.

Tanken

Hösten 2018 aktiverades de första smarta kontrakten i blockchainen Waves, och omedelbart uppstod frågan om möjligheten att få tag påpseudorandomnummer , som man kan lita på.När jag funderade på denna fråga kom jag slutligen fram till slutsatsen: varje blockchain är en cell, det är omöjligt att få en betrodd källa till entropi i ett slutet system.

Men en idé gillade jag ändå: om en

slumptalsorekel använder en deterministisk algoritm för att signera användardata, kan användaren alltid verifiera en sådan signatur med hjälp av den offentliga nyckeln och vara säker på att det erhållna värdet är unikt. Orokeln kan mycket väl inte ändra någonting, algoritmen ger ett entydigt resultat. I själva verket registrerar användaren resultatet, men känner inte till det förrän orakeln publicerar det. Det visar sig att man i själva verket inte behöver lita på orakeln, utan istället kan verifiera resultatet av dess arbete. Vid framgångsrik verifiering kan en sådan signatur betraktas som en källa till entropi för ett pseudorandomnummer. I blockchain-plattformen Waves används en signaturordning

EdDSA . I detta system består signaturen av värdena R och S, där R beror på ett slumpmässigt värde, medan S beräknas utifrån det signerade meddelandet, den privata nyckeln och samma slumpmässiga nummer som R. Det visar sig att det inte finns någon entydig beroende; för samma användarmeddelande finns det många giltiga signaturer. en variant Ed25519Det är uppenbart att en sådan signatur i sin rena form inte kan användas som en källa till pseudorandomnummer, eftersom den är icke-deterministisk och därför lätt kan manipuleras av orakeln.

Men det visade sig att det faktiskt är möjligt att göra den determinant.

Jag hade stora förhoppningar på

verifierbar slumpfunktion (VRF) verifierad slumptal funktion (VRF), men efter att ha studerat materien var det nödvändigt att ge upp denna variant. Även om VRF erbjuder en deterministisk variant av signaturen och dess bevis, finns det en konstig del i algoritmen som öppnar en svart mal för manipulationer av oraklet. Det vill säga, vid beräkningen av värdet k (avsnitt 5.1) används en privat nyckel som förblir okänd för användaren, vilket innebär att användaren inte kan verifiera korrektheten i beräkningen av k, vilket gör att oraklet kan använda vilket värde k som helst och samtidigt föra en databas med överensstämmelser mellan k och de signerade uppgifterna, så att de alltid kan återberäkna ett korrekt resultat ur VRF:s perspektiv. Ser ni en dragning baserad på VRF utan att avslöja den privata nyckeln, kan ni gärna påpeka: antingen måste nyckeln avslöjas, eller så måste den uteslutas från beräkningen av k, då kommer den privata nyckeln automatiskt att avslöjas vid den första signaturen. Sammanfattningsvis, som redan sagts, en underlig schema för ett slumpmässigt orakel.

Efter lite överläggningar och med stöd från lokala analytiker föddes ett arbetsschema för VECRO.

VECRO är en förkortning av Verifiable Elliptic Curve Random Oracle, vilket på ryska betyder verifierbart slumpmässigt orakel baserat på elliptiska kurvor.

Det visade sig vara ganska enkelt, för att uppnå determinism måste värdet R fastställas innan det signerade meddelandet uppträder. Om R är fastställt och är en del av det signerade meddelandet, vilket dessutom garanterar att R är fastställt i själva det signerade meddelandet, så bestäms värdet S entydigt av användarens meddelande och kan därför användas som en källa för pseudorandomnummer.

I ett sådant schema är det oviktigt hur R fastställs, det ligger inom oraklets ansvar. Viktigt är att S entydigt definieras av användaren, men dess värde är okänt tills oraklet publicerar det. Precis som vi ville!

När man talar om det fastställda R, observera att återanvända R Att skriva under olika meddelanden avslöjar entydigt den privata nyckeln i EdDSA-schemat. För ägaren av oraklet blir det extremt viktigt att utesluta möjligheten till återanvändning av R för att signera olika användarmeddelanden. Det vill säga, vid alla manipulationer eller samverkan riskerar oraklet alltid att förlora sin privata nyckel.

Sammanfattningsvis måste oraklet erbjuda användarna två funktioner: initialisering, som fastställer värdet R, och signatur, som returnerar värdet S. Paret R, S utgör en vanlig verifierbar signatur av användarens meddelande som innehåller det fasta värdet R och slumpmässiga användardata.

Man kan invända att detta schema för blockchain inte är annat än en vanlig commit-reveal-schema.. I stort sett, ja, det är det. Men det finns några nyanser. För det första arbetar oraklet alltid med samma nyckel i alla operationer, vilket är praktiskt att använda i kontrakt. För det andra finns det en risk att oraklet förlorar sin privata nyckel vid felaktigt beteende, till exempel om oraklet tillåter resultatprovtagning, då räcker det med att göra två prover för att ta reda på den privata nyckeln och få fullständig tillgång till plånboken. För det tredje är den natively verifierbara signaturen i blockchain, som är källan till slumpmässighet - det är vackert.

I ett halvår har idén om implementering mognat i huvudet, tills motivationen slutligen kom i form av en stipendium från Waves Labs.. Med ett stort stipendium kommer ett stort ansvar, vilket innebär att projektet måste bli av!

Implementering

Så, i detta projekt genomfördes VECRO på blockchain Waves i förfrågan-svar-läge genom överföringstransaktioner mellan användaren och oraklet. Samtidigt har oraklets konto ett skript som strikt reglerar arbetet i enlighet med den beskrivna logiken. Oraklets transaktioner genomgår en kontroll som återställer hela kedjan av interaktioner med användaren. Vid kontroll av det slutliga värdet deltar alla fyra transaktioner, smarta kontraktet trär dem på en strikt verifierande tråd, steg för steg kontrollerar alla värden och lämnar inte utrymme för några manipulationer.

Än en gång, för att det ska fastna och bli tydligare. Oraklet arbetar inte bara enligt det föreslagna schemat. Dess arbete kontrolleras helt på blockchain-nivå av det installerade. fast med smartkontrakt. Ett steg åt sidan och transaktionen går helt enkelt inte igenom. Så om transaktionen har kommit in i blockkedjan behöver användaren inte ens kontrollera något, det har redan granskats av hundratals noder i nätverket.

För närvarande är en VECRO lanserad i Waves huvudnät (du kan också lansera din egen, det är inte svårt, bara kolla in exempelkonfigurationen). Nuvarande kod körs på PHP (på WavesKit, som jag nämnde tidigare För att använda oracle-tjänsten krävs:).

Att fastställa R;

Skicka minst 0.005 Waves till orakels alias init@vecr;
- Mottaga R-kod i fältet bilaga i överföringen av 1 R-vecr-token från orakeln till användaren;
- Få en signatur;
Skicka minst 0.005 Waves till orakels alias random@vecr och vara ÅTAGANDE att ange den tidigare mottagna R-koden och ytterligare användardata i bilagefältet;
- Mottaga S-kod i bilagefältet i överföringen av 1 S-vecr-token från orakeln till användaren;
- Använd S-koden som en källa för pseudo-slumptal.
Nyckelpunkter om den aktuella implementationen:

Skickade Waves till orakeln används som avgift för återtransaktionen till användaren, upp till maximala 1 Waves;

R-koden är en konkatenering av byte för symbolen 'R' och 32-byte värdet R i base58 kodning;
R-koden i bilagan ska vara först, användardata kommer efter R-koden;
S-koden är en konkatenering av byte för symbolen 'S' och 32-byte värdet S i base58 kodning;
S är resultatet av moddivision, och därför kan S inte användas som ett fullt 256-bit pseudo-slumptal (detta tal kan anses vara maximalt ett 252-bit pseudo-slumptal);
Det enklaste alternativet är att använda hash från S-koden som pseudo-slumptal.
Exempel på hur man får S-koden:

Initiering: