De la idea a la implementació: modifiquem l'esquema de signatura digital de corba el·líptica existent perquè sigui determinista, i a partir d'ell proporcionem funcions per a l'obtenció de nombres pseudoaleatoris verificables dins de la cadena de blocs.
Idea
A la tardor del 2018, la cadena de blocs Waves va incloure , immediatament va sorgir la pregunta sobre la possibilitat d'obtenir pots confiar.
Desconcertant aquesta pregunta, finalment vaig arribar a la conclusió: qualsevol cadena de blocs és una cèl·lula; és impossible obtenir una font d'entropia de confiança en un sistema tancat.
Però encara em va agradar una idea: si signarà les dades de l'usuari amb un algorisme determinista, llavors l'usuari sempre podrà verificar aquesta signatura mitjançant la clau pública i s'assegurarà que el valor resultant és únic. L'oracle, per molt que vulgui, és incapaç de canviar res; l'algoritme produeix un resultat inequívoc. Bàsicament, l'usuari registra el resultat, però no el coneix fins que l'oracle el publica. Resulta que no podeu confiar en absolut a l'oracle, però comproveu el resultat del seu treball. Aleshores, en cas de verificació correcta, aquesta signatura es pot considerar una font d'entropia per a un nombre pseudoaleatori.
La plataforma de cadena de blocs Waves utilitza un esquema de signatura вариант . En aquest esquema, la signatura consta dels valors R i S, on R depèn d'un valor aleatori, i S es calcula en funció del missatge que s'està signant, la clau privada i el mateix nombre aleatori que R. Resulta que no hi ha cap dependència única per al mateix Hi ha moltes signatures vàlides per a un missatge d'usuari.
Òbviament, en la seva forma pura, aquesta signatura no es pot utilitzar com a font de nombres pseudoaleatoris, ja que no és determinista i, per tant, pot ser manipulada fàcilment per l'oracle.
Però, com va resultar, en realitat és possible fer-ho determinista.
En tenia moltes esperances , però després d'estudiar el maquinari, vaig haver d'abandonar aquesta opció. Tot i que VRF ofereix una versió determinista de la signatura i la seva prova, hi ha un lloc estrany en l'algorisme que obre un forat negre per a la manipulació de l'oracle. És a dir, quan es calcula el valor de k () s'utilitza una clau privada, que segueix sent desconeguda per l'usuari, el que significa que l'usuari no pot verificar la correcció del càlcul de k, el que significa que l'oracle pot utilitzar qualsevol valor de k que necessiti i alhora mantenir una base de dades de correspondències. de k i les dades signades per tal de poder tornar a calcular sempre el resultat correcte des del punt de vista de VRF . Si veieu un dibuix basat en VRF sense revelar la clau privada, podeu ser intel·ligent: indiqueu la necessitat de revelar la clau o excloure-la del càlcul de k, aleshores la clau privada es revelarà automàticament quan aparegui la primera signatura. . En general, com ja s'ha esmentat, un estrany esquema per a un oracle aleatori.
Després de pensar una mica i comptar amb el suport dels analistes locals, va néixer l'esquema de treball VECRO.
VECRO és una abreviatura de Verifiable Elliptic Curve Random Oracle, que en rus significa oracle aleatori verificable en corbes el·líptiques.
Tot va resultar bastant senzill; per aconseguir el determinisme, cal fixar el valor de R abans que aparegui el missatge a signar. Si R està compromès i forma part del missatge que s'està signant, la qual cosa assegura a més que R està compromès en el missatge que s'està signant, el valor de S està determinat exclusivament pel missatge de l'usuari i, per tant, es pot utilitzar com a font per a números pseudoaleatoris.
En aquest esquema, no importa com es fixi R; això segueix sent responsabilitat de l'oracle. És important que S sigui determinat de manera única per l'usuari, però el seu valor es desconeix fins que l'oracle el publica. Tot el que volíem!
Parlant de R fixa, tingueu en compte que en signar diversos missatges, revela de manera única la clau privada de l'esquema EdDSA. Esdevé extremadament important per al propietari de l'oracle eliminar la possibilitat de reutilitzar R per signar diferents missatges d'usuari. És a dir, amb qualsevol manipulació o connivència, l'oracle sempre s'arriscarà a perdre la seva clau privada.
En total, l'oracle ha de proporcionar als usuaris dues funcions: inicialització, que fixa el valor R, i signatura, que retorna el valor S. En aquest cas, el parell R, S és la signatura verificable habitual d'un missatge d'usuari que conté un missatge fix. valor R i dades d'usuari arbitràries.
Es pot argumentar que aquest esquema per a la cadena de blocs no és més que normal . Bàsicament, sí, és ella. Però hi ha diversos matisos. En primer lloc, l'oracle sempre funciona amb la mateixa clau en totes les operacions, per exemple, això és convenient utilitzar-lo en contractes. En segon lloc, hi ha el risc que l'oracle perdi la clau privada si es comporta incorrectament, per exemple, l'oracle us permet fer mostres del resultat, aleshores n'hi ha prou amb fer només dues proves per esbrinar la clau privada i obtenir la totalitat. accés a la cartera. En tercer lloc, una signatura que es pot verificar de manera nativa a la cadena de blocs i és una font d'aleatorietat és bonica.
Durant sis mesos la idea de la implementació va bullir al meu cap, fins que finalment va aparèixer la motivació en forma . Amb una gran subvenció comporta una gran responsabilitat, així que el projecte hi serà!
Implementació
Per tant, en aquest projecte a la cadena de blocs Waves en mode petició-resposta mitjançant transaccions de transferència entre l'usuari i l'oracle. Al mateix temps, s'instal·la un script al compte d'oracle que controla el treball estrictament d'acord amb la lògica descrita anteriorment. Les transaccions d'Oracle es verifiquen i es restaura tota la cadena d'interacció de l'usuari. Les quatre transaccions estan implicades en la verificació del valor final; el contracte intel·ligent les encadena amb un estricte fil de verificació, comprovant tots els valors pas a pas i no deixa espai per a cap manipulació.
Una vegada més, per deixar-ho de banda i deixar-ho més clar. L'oracle no només funciona segons l'esquema proposat. El seu treball està completament controlat a nivell de blockchain pels establerts . Passeu cap a l'esquerra i la transacció simplement no es farà. Per tant, si una transacció s'inclou a la cadena de blocs, l'usuari ni tan sols necessita comprovar res; centenars de nodes de xarxa ja ho han comprovat tot per ell.
Actualment, hi ha un VECRO funcionant a la xarxa principal de Waves (pots executar el teu, no és difícil, només ). El codi actual s'executa en PHP (activat , sobre la qual cosa ).
Per utilitzar el servei d'oracle heu de:
- Fixar R;
- Envieu almenys 0.005 Waves a l'àlies de l'oracle init@vecr;
- Rebreu el codi R al camp adjunt a la transferència d'1 testimoni R-vecr de l'oracle a l'usuari;
- Obteniu una signatura;
- Envieu almenys 0.005 Waves a l'àlies de l'oracle random@vecr, i també HA d'indicar el codi R rebut prèviament i les dades addicionals d'usuari al camp adjunt;
- Rebeu el codi S al camp adjunt en la transferència d'1 testimoni S-vecr de l'oracle a l'usuari;
- Utilitzeu el codi S com a font de nombre pseudoaleatori.
Matisos de la implementació actual:
- Les ones enviades a l'oracle s'utilitzen com a comissió per a la transacció de devolució a l'usuari, fins a un màxim d'1 Waves;
- El codi R és la concatenació d'un byte del caràcter "R" i un valor R de 32 bytes codificat en base58;
- El codi R adjunt hauria de ser el primer, les dades de l'usuari apareixen després del codi R;
- El codi S és la concatenació d'un byte del caràcter 'S' i un valor codificat en base32 de 58 bytes de S;
- S és el resultat de la divisió mòdul, de manera que no podeu utilitzar S com un nombre pseudoaleatori complet de 256 bits (aquest nombre es pot considerar com un nombre pseudoaleatori de 252 bits com a màxim);
- L'opció més senzilla és utilitzar el hash del codi S com a nombre pseudoaleatori.
Exemple de recepció de codi S:
- Inicialització:
- Obtenció del codi R:
- Consultant el resultat de la signatura del codi R i les dades de l'usuari "aleatories":
- Recepció del codi S:
Des d'un punt de vista tècnic, l'oracle està completament a punt per treballar, podeu utilitzar-lo amb seguretat. Des del punt de vista de l'ús per part de l'usuari mitjà, falta una interfície gràfica convenient, que caldrà esperar.
Estaré encantat de respondre preguntes i acceptar comentaris, gràcies.
Font: www.habr.com