{"id":32343,"date":"2019-10-31T21:46:27","date_gmt":"2019-10-31T18:46:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne\/"},"modified":"2019-10-31T21:46:27","modified_gmt":"2019-10-31T18:46:27","slug":"cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/cluchajnyj-orakul-na-osnove-tsifrovoj-podpisi-v-blokchejne","title":{"rendered":"Oracolo casuale basato su una firma digitale in blockchain","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dall'idea all'implementazione: modifichiamo lo schema esistente della firma digitale su curva ellittica affinch\u00e9 sia deterministico e forniamo, sulla sua base, funzioni per ottenere numeri pseudocasuali verificabili nella blockchain.<\/p>\n

<\/p>\n

\"Oracolo<\/p>\n

<\/a><\/noindex><\/p>\n

Idea<\/h1>\n

<\/p>\n

Nell'autunno del 2018, nella blockchain di Waves furono attivati i primi smart contract<\/a><\/noindex>, subito si pose la questione della possibilit\u00e0 di ottenere numeri pseudocasuali<\/a><\/noindex>, di cui ci si possa fidare.<\/p>\n

<\/p>\n

Riflettendo su questa questione, giunsi infine alla conclusione: qualsiasi blockchain \u00e8 una cella, ottenere una sorgente affidabile di entropia in un sistema chiuso \u00e8 impossibile.<\/p>\n

<\/p>\n

Ma c'era un'idea che mi piaceva: se un oracolo casuale<\/a><\/noindex> 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 \u00e8 unico. L'oracolo, per quanto desideri, non pu\u00f2 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\u00ec 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\u00f2 essere considerata una fonte di entropia per un numero pseudocasuale.<\/p>\n

<\/p>\n

Nella piattaforma blockchain di Waves viene utilizzato uno schema di firma EdDSA<\/a><\/noindex> una versione Ed25519<\/a><\/noindex>. In questo schema, la firma \u00e8 composta dai valori R e S, dove R dipende da un valore casuale e S \u00e8 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.<\/p>\n

<\/p>\n

\u00c8 evidente che una firma di questo tipo non pu\u00f2 essere usata pura come fonte di numeri pseudocasuali, poich\u00e9 non \u00e8 deterministica e, pertanto, pu\u00f2 essere facilmente soggetta a manipolazioni da parte dell'oracolo.<\/p>\n

<\/p>\n

Ma, come si \u00e8 scoperto, renderla deterministica \u00e8 in realt\u00e0 possibile.<\/p>\n

<\/p>\n

Riponevo grandi speranze nella funzione casuale verificabile (VRF)<\/a><\/noindex>, 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'\u00e8 una stranezza nell'algoritmo che apre una falla per le manipolazioni da parte dell'oracolo. In particolare, nel calcolo del valore k (sezione 5.1<\/a><\/noindex>) viene utilizzata una chiave privata, che rimane sconosciuta all'utente; quindi l'utente non pu\u00f2 verificare la correttezza del calcolo di k, il che significa che l'oracolo pu\u00f2 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\u00e0 di rivelare la chiave o di escluderla dal calcolo di k; in tal caso, la chiave privata si riveler\u00e0 automaticamente alla prima firma. In generale, come gi\u00e0 detto, \u00e8 uno schema strano per un oracolo casuale.<\/p>\n

<\/p>\n

Dopo aver riflettuto un po' e avendo il supporto di analisti locali, \u00e8 nata la schematizzazione del lavoro di VECRO.<\/p>\n

<\/p>\n

VECRO \u00e8 l'acronimo di Verifiable Elliptic Curve Random Oracle, che in italiano significa oracolo casuale verificabile su curve ellittiche.<\/p>\n

<\/p>\n

Tutto si \u00e8 rivelato abbastanza semplice; per ottenere una determinazione \u00e8 necessario fissare il valore R prima della comparsa del messaggio firmato. Se R \u00e8 fissato ed \u00e8 parte del messaggio firmato, il che garantisce ulteriormente la fissazione di R nel messaggio stesso, il valore S \u00e8 determinato in modo univoco dal messaggio dell'utente e, pertanto, pu\u00f2 essere utilizzato come sorgente per numeri pseudocasuali.<\/p>\n

<\/p>\n

In uno schema del genere non importa come viene fissato R; resta nella responsabilit\u00e0 dell'oracolo. \u00c8 importante che S sia definito in modo univoco dall'utente, ma il suo valore non \u00e8 noto fino a quando l'oracolo non lo pubblica. Proprio come volevamo!<\/p>\n

<\/p>\n

Parlando di R fissato, notate che R riutilizzato<\/a><\/noindex> La firma di vari messaggi rivela inequivocabilmente la chiave privata nello schema EdDSA. Per il proprietario dell'oracolo diventa estremamente importante escludere la possibilit\u00e0 di riutilizzare R per firmare messaggi diversi dell'utente. Cio\u00e8, in qualsiasi manipolazione o cospirazione, l'oracolo correr\u00e0 sempre il rischio di perdere la propria chiave privata.<\/p>\n

<\/p>\n

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 \u00e8 una firma verificabile convenzionale del messaggio dell'utente che contiene un valore fisso di R e dati arbitrary dell'utente.<\/p>\n

<\/p>\n

Si potrebbe obiettare che questo schema per la blockchain non \u00e8 altro che una normale schema commit-rivelazione<\/a><\/noindex>. In sostanza, s\u00ec, lo \u00e8. Ma ci sono alcuni dettagli. In primo luogo, l'oracolo lavora sempre con la stessa chiave in tutte le operazioni, ad esempio \u00e8 comodo utilizzarlo nei contratti. In secondo luogo, c'\u00e8 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 \u00e8 la fonte di casualit\u00e0, \u00e8 affascinante.<\/p>\n

<\/p>\n

Per sei mesi l'idea di implementazione ha rodato nella mia testa, finch\u00e9 finalmente non \u00e8 emersa la motivazione sotto forma di un grant da Waves Labs<\/a><\/noindex>. Con un grande grant arriva una grande responsabilit\u00e0, quindi il progetto deve essere realizzato!<\/p>\n

<\/p>\n

Implementazione<\/h1>\n

<\/p>\n

Quindi, in questo progetto VECRO \u00e8 stato implementato<\/a><\/noindex> sulla blockchain di Waves in modalit\u00e0 richiesta-risposta tramite transazioni di trasferimento tra l'utente e l'oracolo. A questo punto, nel conto dell'oracolo \u00e8 stato impostato uno script che controlla il funzionamento rigorosamente in conformit\u00e0 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.<\/p>\n

<\/p>\n

Ancora una volta, per rimanere impresso e rendere tutto pi\u00f9 chiaro. L'oracolo non funziona semplicemente secondo lo schema proposto. Il suo funzionamento \u00e8 completamente controllato a livello di blockchain. un contratto intelligente a prova di errore<\/a><\/noindex>. Un passo a sinistra e la transazione semplicemente non passer\u00e0. Quindi, se la transazione \u00e8 entrata nella blockchain, l'utente non deve nemmeno controllare nulla, perch\u00e9 tutto \u00e8 gi\u00e0 stato verificato da centinaia di nodi della rete.<\/p>\n

<\/p>\n

Attualmente, nella rete principale di Waves \u00e8 stato lanciato un VECRO (puoi avviarne uno tuo, non \u00e8 difficile, basta dare un'occhiata all'esempio di configurazione<\/a><\/noindex>). Il codice attuale funziona su PHP (su WavesKit<\/a><\/noindex>, di cui ho parlato in precedenza<\/a><\/noindex>).<\/p>\n

<\/p>\n

Per utilizzare il servizio dell'oracolo \u00e8 necessario:<\/p>\n

<\/p>\n