Van idee naar uitvoering: we modificeren het bestaande schema voor digitale handtekeningen op een elliptische kromme, zodat het deterministisch wordt, en bieden op basis daarvan functies voor het verkrijgen van verifieerbare pseudowillekeurige getallen binnen de blockchain.
Idee
In het najaar van 2018 werden de eerste slimme contracten geactiveerd in de Waves blockchain, pseudowillekeurige getallen Nadat ik hierover had nagedacht, kwam ik tot de conclusie: elke blockchain is een afgesloten systeem, en het is onmogelijk om een betrouwbare bron van entropie in een gesloten systeem te verkrijgen.
Maar er was één idee dat me aansprak: als een
willekeurige oracle In het blockchainplatform Waves wordt het handtekening-schema
EdDSA optie Het is duidelijk dat zulke handtekeningen in pure vorm niet kunnen worden gebruikt als bron van pseudowillekeurige getallen, aangezien ze niet-deterministisch zijn en derhalve gemakkelijk kunnen worden gemanipuleerd door de oracle.
Maar, zoals bleek, is het in feite mogelijk om het deterministisch te maken.
Ik had hoge verwachtingen van
de verifieerbare willekeurige functie (VRF) , maar na het bestuderen van de materie moesten we van deze optie afzien. Hoewel VRF een deterministische optie voor de ondertekening en het bewijs ervan biedt, bevat het algoritme een vreemde plek die een zwarte doos opent voor manipulaties door de oracle. Namelijk, bij de berekening van de waarde k () wordt een privésleutel gebruikt, die onbekend blijft voor de gebruiker, wat betekent dat de gebruiker de correctheid van de berekening van k niet kan verifiëren. Dit houdt in dat de oracle elke gewenste waarde van k kan gebruiken en tegelijkertijd een database kan bijhouden van de overeenkomsten tussen k en de te ondertekenen gegevens, zodat hij altijd de juiste, vanuit het perspectief van VRF, resultaten kan opnieuw berekenen. Als je een loting op basis van VRF ziet zonder het onthullen van de privésleutel, kun je wijsdoen: aangeven dat het noodzakelijk is om ofwel de sleutel te onthullen of deze uit de berekening van k te sluiten; dan zal de privésleutel automatisch worden onthuld bij de eerste ondertekening. Kortom, zoals al gezegd, een vreemde opzet voor een willekeurige oracle.
Na wat nagedacht te hebben en met de steun van lokale analisten, is het werkingsschema van VECRO ontstaan.
VECRO is een afkorting van Verifiable Elliptic Curve Random Oracle, wat in het Nederlands betekent: verifieerbare willekeurige oracle op elliptische krommen.
Het bleek vrij eenvoudig te zijn; om determinisme te bereiken, moet de waarde R worden vastgelegd voordat het te ondertekenen bericht verschijnt. Als R is vastgelegd en onderdeel is van het te ondertekenen bericht, wat bovendien garandeert dat R in het te ondertekenen bericht zelf is vastgelegd, kan de waarde S eenduidig worden bepaald door het gebruikersbericht en kan dus worden gebruikt als bron voor pseudowillekeurige getallen.
In zo'n schema is het niet belangrijk op welke manier R wordt vastgelegd; dit blijft de verantwoordelijkheid van de oracle. Belangrijk is dat S eenduidig wordt bepaald door de gebruiker, maar de waarde ervan is onbekend totdat de oracle deze publiceert. Alles zoals we wilden!
Als we het hebben over het vaste R, let dan op dat Bij het ondertekenen van verschillende berichten onthult het onmiskenbaar de privésleutel in het EdDSA-schema. Voor de eigenaar van de oracle is het van cruciaal belang om de mogelijkheid van hergebruik van R voor het ondertekenen van verschillende berichten van de gebruiker uit te sluiten. Dat wil zeggen, bij elke manipulatie of samenzwering zal de oracle altijd het risico lopen zijn privésleutel te verliezen.
Samengevat moet de oracle de gebruikers twee functies bieden: initialisatie, die de waarde R vastlegt, en ondertekening, die de waarde S retourneert. Hierbij is het paar R, S een gewone controleerbare ondertekening van het gebruikersbericht dat een vaste waarde R en willekeurige gebruikersgegevens bevat.
Men kan aanvoeren dat dit schema voor blockchain niets meer is dan een gewone . In feite is dat het ook. Maar er zijn een paar nuances. Ten eerste werkt de oracle altijd met dezelfde sleutel in alle operaties, wat bijvoorbeeld handig is om te gebruiken in contracten. Ten tweede bestaat het risico dat de oracle zijn privésleutel verliest bij onjuist gedrag; als de oracle bijvoorbeeld de mogelijkheid biedt om monsterproeven van het resultaat te nemen, is het voldoende om slechts twee monsterproeven te nemen om de privésleutel te achterhalen en volledige toegang tot de portemonnee te krijgen. Ten derde is de in de blockchain native controleerbare ondertekening, die een bron van willekeurigheid is — dat is mooi.
Zes maanden lang heeft het idee van implementatie in mijn hoofd gekauwd, totdat er eindelijk motivatie kwam in de vorm van . Met een grote subsidie komt een grote verantwoordelijkheid, dus het project moet er komen!
Implementatie
Dus in dit project op de Waves blockchain in een request-response modus met behulp van transfertransacties tussen de gebruiker en de oracle. Op het account van de oracle is er een script ingesteld dat de werking strikt volgens de hierboven beschreven logica controleert. De transacties van de oracle worden gecontroleerd met herstel van de gehele interactieketen met de gebruiker. Bij het controleren van de uiteindelijke waarde zijn alle vier de transacties betrokken, waarbij het smart contract ze aan een strikte controleerbare draad rijgt, stap voor stap alle waarden controleert en geen ruimte laat voor enige manipulatie.
Nogmaals, zodat het blijft hangen en duidelijker is. De oracle werkt niet gewoon volgens het voorgestelde schema. Zijn werk wordt volledig gecontroleerd op blockchainniveau door het geïnstalleerde . Een stap naar links en de transactie zal gewoon niet doorgaan. Dus, als de transactie in de blockchain is gekomen, hoeft de gebruiker zelfs niets te controleren; dat hebben honderden knooppunten in het netwerk al voor hem gedaan.
Op dit moment is er één VECRO in het mainnet van Waves gelanceerd (je kunt er zelf een lanceren, het is niet moeilijk, gewoon ). De huidige code werkt op PHP (op de , waarover ).
Om gebruik te maken van de oracle service, is het noodzakelijk:
- R vast te leggen;
- Minimaal 0.005 Waves naar het oracle alias init@vecr te sturen;
- R-code te ontvangen in het bijlageveld in de overdracht van 1 R-vecr token van de oracle naar de gebruiker;
- Een handtekening te ontvangen;
- Minimaal 0.005 Waves naar het oracle alias random@vecr te sturen, en daarnaast moet je beslist in het bijlageveld de eerder verkregen R-code en aanvullende gebruikersgegevens opgeven;
- S-code te ontvangen in het bijlageveld in de overdracht van 1 S-vecr token van de oracle naar de gebruiker;
- S-code te gebruiken als bron van pseudo-willekeurig nummer.
Specifieke details van de huidige implementatie:
- Sent Waves naar de oracle worden gebruikt als commissie voor de terugzending aan de gebruiker, tot een maximum van 1 Waves;
- R-code is een concatenatie van de byte van het symbool 'R' en de 32-byte waarde R in base58 codering;
- R-code in de bijlage moet eerst staan, de gebruikersgegevens komen na de R-code;
- S-code is een concatenatie van de byte van het symbool 'S' en de 32-byte waarde S in base58 codering;
- S is het resultaat van de modulo-berekening, daarom kan S niet worden gebruikt als een volledig 256-bits pseudo-willekeurig nummer (dit nummer kan maximaal als een 252-bits pseudo-willekeurig nummer worden beschouwd);
- De eenvoudigste optie is om de hash van de S-code als pseudo-willekeurig nummer te gebruiken.
Voorbeeld van het verkrijgen van S-code:
- Initiatie:
- Verkrijgen van R-code:
- Verzoek om het resultaat van de handtekening R-code en de gebruikersgegevens “random”:
- Verkrijgen van S-code:
Vanuit technisch perspectief is de oracle volledig operationeel, je kunt het gerust gebruiken. Vanuit het perspectief van de gemiddelde gebruiker ontbreekt een gebruiksvriendelijke grafische interface; daar moeten we nog op wachten.
Ik beantwoord graag vragen en ontvang opmerkingen, bedankt.
Bron: habr.com
