Dall'idea all'implementazione: modifichiamo lo schema esistente della firma digitale su curva ellittica affinché sia deterministico e forniamo, sulla sua base, funzioni per ottenere numeri pseudocasuali verificabili nella blockchain.
Idea
Nell'autunno del 2018, nella blockchain di Waves furono , subito si pose la questione della possibilità di ottenere , di cui ci si possa fidare.
Riflettendo su questa questione, giunsi infine alla conclusione: qualsiasi blockchain è una cella, ottenere una sorgente affidabile di entropia in un sistema chiuso è impossibile.
Ma c'era un'idea che mi piaceva: se un dovesse firmare i dati degli utenti con un algoritmo deterministico, allora l'utente potrebbe sempre verificare tale firma con la chiave pubblica e sarebbe certo che il valore ottenuto è unico. L'oracolo, per quanto desideri, non può cambiare nulla; l'algoritmo fornisce un risultato univoco. Di fatto, l'utente fissa il risultato, ma non lo conosce fino a che l'oracolo non lo pubblica. Si arriva così alla conclusione che non si debba affidarsi all'oracolo, ma verificare il risultato del suo lavoro. In tal modo, nel caso di una verifica positiva, tale firma può essere considerata una fonte di entropia per un numero pseudocasuale.
Nella piattaforma blockchain di Waves viene utilizzato uno schema di firma una versione . In questo schema, la firma è composta dai valori R e S, dove R dipende da un valore casuale e S è calcolato sulla base del messaggio firmato, della chiave privata e dello stesso numero casuale di R. Risulta quindi che non esiste una dipendenza univoca; per lo stesso messaggio degli utenti esistono molte firme valide.
È evidente che una firma di questo tipo non può essere usata pura come fonte di numeri pseudocasuali, poiché non è deterministica e, pertanto, può essere facilmente soggetta a manipolazioni da parte dell'oracolo.
Ma, come si è scoperto, renderla deterministica è in realtà possibile.
Riponevo grandi speranze nella , ma dopo aver studiato la parte tecnica, abbiamo dovuto rinunciare a questa opzione. Sebbene il VRF offra un'opzione deterministica per la firma e la sua prova, c'è una stranezza nell'algoritmo che apre una falla per le manipolazioni da parte dell'oracolo. In particolare, nel calcolo del valore k () viene utilizzata una chiave privata, che rimane sconosciuta all'utente; quindi l'utente non può verificare la correttezza del calcolo di k, il che significa che l'oracolo può utilizzare qualsiasi valore k desideri e allo stesso tempo tenere un database delle corrispondenze k e dei dati firmati, per poter sempre rieseguire il risultato corretto dal punto di vista del VRF. Se vedete un'estrazione basata su VRF senza rivelare la chiave privata, potete fare il saputello: segnalare la necessità di rivelare la chiave o di escluderla dal calcolo di k; in tal caso, la chiave privata si rivelerà automaticamente alla prima firma. In generale, come già detto, è uno schema strano per un oracolo casuale.
Dopo aver riflettuto un po' e avendo il supporto di analisti locali, è nata la schematizzazione del lavoro di VECRO.
VECRO è l'acronimo di Verifiable Elliptic Curve Random Oracle, che in italiano significa oracolo casuale verificabile su curve ellittiche.
Tutto si è rivelato abbastanza semplice; per ottenere una determinazione è necessario fissare il valore R prima della comparsa del messaggio firmato. Se R è fissato ed è parte del messaggio firmato, il che garantisce ulteriormente la fissazione di R nel messaggio stesso, il valore S è determinato in modo univoco dal messaggio dell'utente e, pertanto, può essere utilizzato come sorgente per numeri pseudocasuali.
In uno schema del genere non importa come viene fissato R; resta nella responsabilità dell'oracolo. È importante che S sia definito in modo univoco dall'utente, ma il suo valore non è noto fino a quando l'oracolo non lo pubblica. Proprio come volevamo!
Parlando di R fissato, notate che La firma di vari messaggi rivela inequivocabilmente la chiave privata nello schema EdDSA. Per il proprietario dell'oracolo diventa estremamente importante escludere la possibilità di riutilizzare R per firmare messaggi diversi dell'utente. Cioè, in qualsiasi manipolazione o cospirazione, l'oracolo correrà sempre il rischio di perdere la propria chiave privata.
Pertanto, l'oracolo deve fornire agli utenti due funzioni: l'inizializzazione, che fissa il valore di R, e la firma, che restituisce il valore di S. In questo caso, la coppia R, S è una firma verificabile convenzionale del messaggio dell'utente che contiene un valore fisso di R e dati arbitrary dell'utente.
Si potrebbe obiettare che questo schema per la blockchain non è altro che una normale . In sostanza, sì, lo è. Ma ci sono alcuni dettagli. In primo luogo, l'oracolo lavora sempre con la stessa chiave in tutte le operazioni, ad esempio è comodo utilizzarlo nei contratti. In secondo luogo, c'è il rischio di perdita della chiave privata da parte dell'oracolo in caso di comportamento scorretto, ad esempio, se l'oracolo consente di fare campionamenti dei risultati, allora basta fare solo due campionamenti per scoprire la chiave privata e avere accesso completo al portafoglio. In terzo luogo, la firma nativamente verificabile nella blockchain, che è la fonte di casualità, è affascinante.
Per sei mesi l'idea di implementazione ha rodato nella mia testa, finché finalmente non è emersa la motivazione sotto forma di . Con un grande grant arriva una grande responsabilità, quindi il progetto deve essere realizzato!
Implementazione
Quindi, in questo progetto sulla blockchain di Waves in modalità richiesta-risposta tramite transazioni di trasferimento tra l'utente e l'oracolo. A questo punto, nel conto dell'oracolo è stato impostato uno script che controlla il funzionamento rigorosamente in conformità con la logica descritta sopra. Le transazioni dell'oracolo passano una verifica con il ripristino dell'intera catena di interazione con l'utente. Nella verifica del valore finale partecipano tutte e quattro le transazioni, il contratto intelligente le intreccia su un rigoroso filo di verifica, controllando passo dopo passo tutti i valori e non lasciando spazio per alcuna manipolazione.
Ancora una volta, per rimanere impresso e rendere tutto più chiaro. L'oracolo non funziona semplicemente secondo lo schema proposto. Il suo funzionamento è completamente controllato a livello di blockchain. . Un passo a sinistra e la transazione semplicemente non passerà. Quindi, se la transazione è entrata nella blockchain, l'utente non deve nemmeno controllare nulla, perché tutto è già stato verificato da centinaia di nodi della rete.
Attualmente, nella rete principale di Waves è stato lanciato un VECRO (puoi avviarne uno tuo, non è difficile, basta ). Il codice attuale funziona su PHP (su , di cui ).
Per utilizzare il servizio dell'oracolo è necessario:
- Fissare R;
- Inviare un minimo di 0.005 Waves all'alias dell'oracolo init@vecr;
- Ricevere il R-code nel campo attachment nel trasferimento di 1 token R-vecr dall'oracolo all'utente;
- Ottenere la firma;
- Inviare un minimo di 0.005 Waves all'alias dell'oracolo random@vecr, e è OBBLIGATORIO indicare nel campo attachment il R-code ottenuto in precedenza e ulteriori dati dell'utente;
- Ricevere il S-code nel campo attachment nel trasferimento di 1 token S-vecr dall'oracolo all'utente;
- Utilizzare il S-code come fonte di numero pseudo-casuale.
Aspetti della implementazione attuale:
- Le Waves inviate all'oracolo vengono utilizzate come commissione per il trasferimento all'utente, fino a un massimo di 1 Waves;
- Il R-code è la concatenazione del byte del carattere 'R' e 32 byte del valore R in codifica base58;
- Il R-code nell'attachment deve trovarsi per primo, i dati dell'utente seguono il R-code;
- Il S-code è la concatenazione del byte del carattere 'S' e 32 byte del valore S in codifica base58;
- S è il risultato di una divisione modulo, quindi non si può usare S come un numero pseudo-casuale a 256 bit (questo numero può essere considerato al massimo un numero pseudo-casuale a 252 bit);
- L'opzione più semplice è utilizzare l'hash del S-code come numero pseudo-casuale.
Esempio di ottenimento del S-code:
- Inizializzazione:
- Ottenimento del R-code:
- Richiesta del risultato della firma del R-code e dei dati dell'utente 'random':
- Ottenimento del S-code:
Dal punto di vista tecnico, l'oracolo è completamente pronto per l'uso, puoi tranquillamente utilizzarlo. Dal punto di vista dell'utente medio, manca un'interfaccia grafica comoda, ma dovremo aspettare.
Sarò felice di rispondere alle domande e accettare suggerimenti, grazie.
Fonte: habr.com
