Från idé till implementering: vi modifierar det befintliga digitala signaturschemat för elliptiska kurvor så att det är deterministiskt, och baserat på det tillhandahåller vi funktioner för att erhålla pseudoslumptal som kan verifieras inom blockkedjan.
Idé
Hösten 2018 ingick Waves blockchain , uppstod omedelbart frågan om möjligheten att erhålla som du kan lita på.
Förbryllande över denna fråga kom jag till slut till slutsatsen: vilken blockkedja som helst är en cell; det är omöjligt att få en pålitlig källa till entropi i ett slutet system.
Men jag gillade ändå en idé: om kommer att signera användardata med en deterministisk algoritm, då kommer användaren alltid att kunna verifiera en sådan signatur med den publika nyckeln, och kommer att vara säker på att det resulterande värdet är unikt. Oraklet, hur hårt det än vill, kan inte ändra någonting, algoritmen ger ett entydigt resultat. I huvudsak registrerar användaren resultatet, men vet det inte förrän oraklet publicerar det. Det visar sig att du inte kan lita på oraklet alls, men kontrollera resultatet av dess arbete. Sedan, i händelse av framgångsrik verifiering, kan en sådan signatur betraktas som en källa till entropi för ett pseudoslumptal.
Waves blockchain-plattform använder ett signaturschema вариант . I detta schema består signaturen av värdena R och S, där R beror på ett slumpmässigt värde, och S beräknas utifrån meddelandet som signeras, den privata nyckeln och samma slumptal som R. Det visar sig att det finns inget unikt beroende för samma Det finns många giltiga signaturer för ett användarmeddelande.
Uppenbarligen, i sin rena form, kan en sådan signatur inte användas som en källa till pseudoslumptal, eftersom den är icke-deterministisk och därför lätt kan manipuleras av oraklet.
Men, som det visade sig, är det faktiskt möjligt att göra det deterministiskt.
Jag hade stora förhoppningar om , men efter att ha studerat hårdvaran var jag tvungen att överge det här alternativet. Även om VRF erbjuder en deterministisk version av signaturen och dess bevis, finns det en konstig plats i algoritmen som öppnar ett svart hål för manipulation av oraklet. Nämligen när man beräknar värdet av k () en privat nyckel används, som förblir okänd för användaren, vilket innebär att användaren inte kan verifiera korrektheten av beräkningen av k, vilket innebär att oraklet kan använda vilket värde på k som det behöver och samtidigt upprätthålla en databas med korrespondenser av k och de signerade uppgifterna för att alltid kunna räkna om det korrekta resultatet ur VRF-synpunkt . Om du ser en ritning baserad på VRF utan att avslöja den privata nyckeln, kan du vara smart: ange behovet av att antingen avslöja nyckeln, eller utesluta den från beräkningen av k, då kommer den privata nyckeln automatiskt att avslöja sig själv när den första signaturen visas . I allmänhet, som redan nämnts, ett konstigt schema för ett slumpmässigt orakel.
Efter lite funderande och efter att ha fått stöd från lokala analytiker föddes VECRO-arbetsprogrammet.
VECRO är en förkortning för Verifiable Elliptic Curve Random Oracle, vilket på ryska betyder verifierbart slumpmässigt orakel på elliptiska kurvor.
Allt visade sig vara ganska enkelt; för att uppnå determinism måste du fixa värdet på R innan meddelandet som ska signeras visas. Om R är committed och är en del av meddelandet som signeras, vilket ytterligare säkerställer att R committeras i meddelandet som signeras, bestäms värdet på S unikt av användarens meddelande och kan därför användas som källa för pseudoslumptal.
I ett sådant schema spelar det ingen roll hur R är fixerat, detta är fortfarande oraklets ansvar. Det är viktigt att S är unikt bestämt av användaren, men dess värde är okänt tills oraklet publicerar det. Allt vi ville ha!
På tal om fast R, notera det när du signerar olika meddelanden avslöjar den unikt den privata nyckeln i EdDSA-schemat. Det blir oerhört viktigt för ägaren av oraklet att eliminera möjligheten att återanvända R för att signera olika användarmeddelanden. Det vill säga, med all manipulation eller maskopi kommer oraklet alltid att riskera att förlora sin privata nyckel.
Totalt måste oraklet förse användare med två funktioner: initiering, som fixerar värdet R, och signatur, som returnerar värdet S. I detta fall är paret R, S den vanliga verifierbara signaturen för ett användarmeddelande som innehåller en fixerad värde R och godtyckliga användardata.
Det kan hävdas att detta schema för blockkedjan inte är något annat än vanligt . I huvudsak, ja, det är det här. Men det finns flera nyanser. För det första arbetar oraklet alltid med samma nyckel i alla operationer, till exempel är detta bekvämt att använda i kontrakt. För det andra finns det en risk att oraklet tappar bort den privata nyckeln om det beter sig felaktigt, till exempel låter oraklet dig göra prover på resultatet, då räcker det med att bara göra två tester för att ta reda på den privata nyckeln och få full tillgång till plånboken. För det tredje är en signatur som är inbyggt verifierbar på blockkedjan och är en källa till slumpmässighet vacker.
I sex månader puttrade idén om implementering i mitt huvud, tills motivationen äntligen dök upp i formen . Med ett stort bidrag kommer ett stort ansvar, så projektet kommer att finnas där!
genomförande
Så i det här projektet på Waves blockchain i begäran-svar-läge med hjälp av överföringstransaktioner mellan användaren och oraklet. Samtidigt installeras ett skript på oracle-kontot som styr arbetet strikt i enlighet med logiken som beskrivs ovan. Oracle-transaktioner verifieras och hela kedjan av användarinteraktion återställs. Alla fyra transaktionerna är inblandade i att verifiera det slutliga värdet; det smarta kontraktet sammanfogar dem med en strikt verifieringstråd, kontrollerar alla värden steg för steg och lämnar inget utrymme för någon manipulation.
Återigen, för att lägga det åt sidan och göra det tydligare. Oraklet fungerar inte bara enligt det föreslagna schemat. Dess arbete är helt kontrollerat på blockchain-nivå av de etablerade . Gå till vänster och transaktionen går helt enkelt inte igenom. Så om en transaktion ingår i blockkedjan behöver användaren inte ens kontrollera någonting; hundratals nätverksnoder har redan kontrollerat allt för honom.
För närvarande finns det en VECRO som körs på Waves huvudnät (du kan köra ditt eget, det är inte svårt, bara ). Den aktuella koden körs i PHP (på , om vilken ).
För att använda orakeltjänsten måste du:
- Fixa R;
- Skicka minst 0.005 vågor till oracle alias init@vecr;
- Ta emot R-koden i det bifogade fältet vid överföringen av 1 R-vecr-token från oraklet till användaren;
- Skaffa en signatur;
- Skicka minst 0.005 vågor till oraklets alias random@vecr, och MÅSTE även ange den tidigare mottagna R-koden och ytterligare användardata i bifogade fält;
- Ta emot S-koden i det bifogade fältet vid överföringen av 1 S-vecr-token från oraklet till användaren;
- Använd S-kod som en källa för pseudoslumptal.
Nyanser av den nuvarande implementeringen:
- Vågor som skickas till oraklet används som en provision för returtransaktionen till användaren, upp till maximalt 1 vågor;
- R-kod är sammanlänkningen av en byte med tecknet 'R' och ett 32-byte base58-kodat R-värde;
- R-koden i bilagan ska vara först, användardata kommer efter R-koden;
- S-kod är sammanlänkningen av en byte med tecknet 'S' och ett 32-byte base58-kodat värde på S;
- S är resultatet av modulo division, så du kan inte använda S som ett fullständigt 256-bitars pseudoslumptal (detta nummer kan betraktas som ett maximalt 252-bitars pseudoslumptal);
- Det enklaste alternativet är att använda S-kodens hash som ett pseudoslumptal.
Exempel på att ta emot S-kod:
- Initiering:
- Få R-kod:
- Fråga resultatet av R-kodsignering och användardata "slumpmässigt":
- Tar emot S-kod:
Ur teknisk synvinkel är oraklet helt redo för arbete, du kan säkert använda det. Ur den genomsnittliga användarens användningssynpunkt saknas ett bekvämt grafiskt gränssnitt, detta får vänta.
Jag svarar gärna på frågor och accepterar kommentarer, tack.
Källa: will.com