Van idee tot implementatie: we passen het bestaande digitale handtekeningschema met de elliptische curve aan zodat het deterministisch is, en op basis daarvan bieden we functies voor het verkrijgen van pseudo-willekeurige getallen die verifieerbaar zijn binnen de blockchain.
Idee
In het najaar van 2018 werd de Waves-blockchain opgenomen , rees meteen de vraag over de mogelijkheid om te verkrijgen waarop u kunt vertrouwen.
Terwijl ik over deze vraag puzzelde, kwam ik uiteindelijk tot de conclusie: elke blockchain is een cel; het is onmogelijk om een betrouwbare bron van entropie te verkrijgen in een gesloten systeem.
Maar ik vond nog steeds één idee leuk: als Als gebruikersgegevens worden ondertekend met een deterministisch algoritme, kan de gebruiker een dergelijke handtekening altijd verifiëren met behulp van de publieke sleutel, en weet hij zeker dat de resulterende waarde uniek is. Het orakel kan, hoe hard het ook wil, niets veranderen; het algoritme levert een eenduidig resultaat op. In wezen registreert de gebruiker het resultaat, maar weet het pas als het orakel het publiceert. Het blijkt dat je het orakel helemaal niet kunt vertrouwen, maar het resultaat van zijn werk kunt controleren. In geval van succesvolle verificatie kan een dergelijke handtekening vervolgens worden beschouwd als een bron van entropie voor een pseudo-willekeurig getal.
Het Waves blockchain-platform maakt gebruik van een handtekeningschema вариант . In dit schema bestaat de handtekening uit de waarden R en S, waarbij R afhankelijk is van een willekeurige waarde, en S wordt berekend op basis van het bericht dat wordt ondertekend, de privésleutel en hetzelfde willekeurige getal als R. Het blijkt dat er is geen unieke afhankelijkheid voor hetzelfde. Er zijn veel geldige handtekeningen voor een gebruikersbericht.
Het is duidelijk dat een dergelijke handtekening in zijn pure vorm niet kan worden gebruikt als bron van pseudo-willekeurige getallen, aangezien deze niet-deterministisch is en daarom gemakkelijk door het orakel kan worden gemanipuleerd.
Maar het bleek feitelijk mogelijk om het deterministisch te maken.
Ik had er grote verwachtingen van , maar nadat ik de hardware had bestudeerd, moest ik van deze optie afzien. Hoewel VRF een deterministische versie van de handtekening en het bewijs ervan biedt, is er een vreemde plek in het algoritme die een zwart gat opent voor manipulatie van het orakel. Namelijk bij het berekenen van de waarde van k () er wordt een privésleutel gebruikt, die onbekend blijft voor de gebruiker, wat betekent dat de gebruiker de juistheid van de berekening van k niet kan verifiëren, wat betekent dat het orakel elke waarde van k kan gebruiken die het nodig heeft en tegelijkertijd een database met correspondenties kan bijhouden van k en de ondertekende gegevens om altijd het juiste resultaat te kunnen herberekenen vanuit het oogpunt van VRF. Als je een tekening ziet op basis van VRF zonder de privésleutel vrij te geven, kun je slim zijn: geef aan dat het nodig is om de sleutel te onthullen, of deze uit te sluiten van de berekening van k, dan zal de privésleutel zichzelf automatisch onthullen wanneer de eerste handtekening verschijnt . Over het algemeen, zoals reeds vermeld, een vreemd schema voor een willekeurig orakel.
Na even nadenken en de steun van lokale analisten inroepen, werd het VECRO-werkprogramma geboren.
VECRO is een afkorting voor Verifiable Elliptic Curve Random Oracle, wat in het Russisch verifieerbaar willekeurig orakel op elliptische curven betekent.
Alles bleek vrij eenvoudig: om determinisme te bereiken, moet je de waarde van R vastleggen voordat het te ondertekenen bericht verschijnt. Als R is vastgelegd en deel uitmaakt van het bericht dat wordt ondertekend, wat er verder voor zorgt dat R wordt vastgelegd in het bericht dat wordt ondertekend, wordt de waarde van S op unieke wijze bepaald door het bericht van de gebruiker en kan daarom worden gebruikt als bron voor pseudowillekeurige getallen.
In een dergelijk schema maakt het niet uit hoe R vastligt; dit blijft de verantwoordelijkheid van het orakel. Het is belangrijk dat S uniek wordt bepaald door de gebruiker, maar de waarde ervan is onbekend totdat het orakel het publiceert. Alles wat we wilden!
Over vaste R gesproken, merk dat op bij het ondertekenen van verschillende berichten wordt op unieke wijze de privésleutel in het EdDSA-schema onthuld. Het wordt uiterst belangrijk voor de eigenaar van het orakel om de mogelijkheid te elimineren om R te hergebruiken om verschillende gebruikersberichten te ondertekenen. Dat wil zeggen dat het orakel bij elke manipulatie of samenzwering altijd het risico loopt zijn privésleutel te verliezen.
In totaal moet het orakel de gebruikers twee functies bieden: initialisatie, die de waarde R vastlegt, en handtekening, die de waarde S retourneert. In dit geval is het paar R, S de gebruikelijke verifieerbare handtekening van een gebruikersbericht dat een vaste waarde bevat. waarde R en willekeurige gebruikersgegevens.
Er kan worden gesteld dat dit schema voor de blockchain niets meer dan gewoon is . In wezen is zij het wel. Maar er zijn verschillende nuances. Ten eerste werkt het orakel bij alle handelingen altijd met dezelfde sleutel, dit is bijvoorbeeld handig om te gebruiken bij contracten. Ten tweede bestaat het risico dat het orakel de privésleutel verliest als het zich onjuist gedraagt. Het orakel staat u bijvoorbeeld toe om voorbeelden van het resultaat te maken. Vervolgens volstaat het om slechts twee tests uit te voeren om de privésleutel te achterhalen en de volledige sleutel te verkrijgen. toegang tot de portemonnee. Ten derde is een handtekening die van nature verifieerbaar is op de blockchain en een bron van willekeur is, prachtig.
Zes maanden lang sudderde het idee van implementatie in mijn hoofd, totdat uiteindelijk de motivatie in de vorm verscheen . Bij een grote subsidie hoort een grote verantwoordelijkheid, dus het project komt er!
uitvoering
Bij dit project dus op de Waves-blockchain in verzoek-antwoordmodus met behulp van overdrachtstransacties tussen de gebruiker en het orakel. Tegelijkertijd wordt op het Oracle-account een script geïnstalleerd dat het werk strikt controleert in overeenstemming met de hierboven beschreven logica. Oracle-transacties worden geverifieerd en de hele keten van gebruikersinteractie wordt hersteld. Alle vier de transacties zijn betrokken bij het verifiëren van de uiteindelijke waarde; het slimme contract koppelt ze aan elkaar met een strikte verificatiedraad, waarbij alle waarden stap voor stap worden gecontroleerd en er geen ruimte overblijft voor enige manipulatie.
Nogmaals, om het opzij te zetten en het duidelijker te maken. Het orakel werkt niet alleen volgens het voorgestelde schema. Het werk wordt op blockchain-niveau volledig gecontroleerd door de gevestigde orde . Ga naar links en de transactie gaat gewoon niet door. Als een transactie dus in de blockchain is opgenomen, hoeft de gebruiker niet eens iets te controleren; honderden netwerkknooppunten hebben alles al voor hem gecontroleerd.
Momenteel draait er één VECRO op het Waves-mainnet (je kunt er zelf een draaien, het is niet moeilijk, alleen ). De huidige code draait in PHP (on , waarover ).
Om de orakelservice te kunnen gebruiken, moet u:
- Repareer R;
- Stuur minimaal 0.005 golven naar orakelalias init@vecr;
- Ontvang de R-code in het bijlageveld bij de overdracht van 1 R-vecr-token van het orakel naar de gebruiker;
- Zorg voor een handtekening;
- Stuur minimaal 0.005 Waves naar de orakelalias random@vecr, en MOET ook de eerder ontvangen R-code en aanvullende gebruikersgegevens in het bijlageveld vermelden;
- Ontvang de S-code in het bijlageveld bij de overdracht van 1 S-vecr-token van het orakel naar de gebruiker;
- Gebruik S-code als bron van pseudo-willekeurige getallen.
Nuances van de huidige implementatie:
- Waves die naar het orakel worden gestuurd, worden gebruikt als commissie voor de retourtransactie naar de gebruiker, tot een maximum van 1 Waves;
- R-code is de aaneenschakeling van een byte van het 'R'-teken en een 32-byte base58-gecodeerde R-waarde;
- R-code in bijlage moet eerst staan, gebruikersgegevens komen na R-code;
- S-code is de aaneenschakeling van een byte van het teken 'S' en een 32-byte base58-gecodeerde waarde van S;
- S is het resultaat van modulo-deling, dus je kunt S niet gebruiken als een volledig pseudowillekeurig getal van 256 bits (dit getal kan worden beschouwd als een maximaal pseudowillekeurig getal van 252 bits);
- De eenvoudigste optie is om de S-code-hash als een pseudo-willekeurig getal te gebruiken.
Voorbeeld van het ontvangen van S-code:
- Initialisatie:
- R-code verkrijgen:
- Het resultaat van R-code-ondertekening en gebruikersgegevens “willekeurig” opvragen:
- S-code ontvangen:
Technisch gezien is het orakel helemaal klaar voor gebruik, je kunt het veilig gebruiken. Vanuit het oogpunt van gebruik door de gemiddelde gebruiker ontbreekt het aan een handige grafische interface; dit zal moeten wachten.
Ik zal graag vragen beantwoorden en opmerkingen accepteren, bedankt.
Bron: www.habr.com