{"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 firma digitale in blockchain","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

<\/p>\n

\"Oracolo<\/p>\n

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

Idea<\/h1>\n

<\/p>\n

Nell'autunno del 2018, nel blockchain di Waves sono stati attivati i primi smart contract<\/a><\/noindex>, \u00e8 emersa immediatamente la questione della possibilit\u00e0 di ottenere numeri pseudocasuali<\/a><\/noindex>, di cui ci si pu\u00f2 fidare.<\/p>\n

<\/p>\n

Riflettendo su questa questione, sono giunto alla conclusione definitiva: qualsiasi blockchain \u00e8 una gabbia, ottenere una fonte attendibile di entropia in un sistema chiuso \u00e8 impossibile.<\/p>\n

<\/p>\n

Ma un'idea mi \u00e8 piaciuta: se un oracolo casuale<\/a><\/noindex> Quando si genera una firma dei dati dell'utente con un algoritmo deterministico, l'utente pu\u00f2 sempre verificare tale firma tramite la chiave pubblica e sar\u00e0 certo che il valore ottenuto \u00e8 unico. Un oracolo, per quanto desideri, non pu\u00f2 modificare nulla; l'algoritmo fornisce un risultato chiaro. In sostanza, l'utente registra il risultato, ma non lo conosce fino a quando l'oracolo non lo pubblica. Di conseguenza, non ci si pu\u00f2 fidare dell'oracolo, ma si pu\u00f2 verificare il risultato del suo lavoro. Se la verifica ha successo, tale firma pu\u00f2 essere considerata fonte di entropia per un numero pseudo-casuale.<\/p>\n

<\/p>\n

Nella piattaforma blockchain Waves viene utilizzato uno schema di firma EdDSA<\/a><\/noindex> una variante Ed25519<\/a><\/noindex>. In questo schema, la firma \u00e8 composta dai valori R e S, dove R dipende da un valore casuale, mentre S viene calcolato sulla base del messaggio da firmare, della chiave privata e dello stesso numero casuale utilizzato per R. Si ottiene quindi che non esiste una dipendenza unica; per lo stesso messaggio dell'utente esistono molte firme valide.<\/p>\n

<\/p>\n

\u00c8 chiaro che una firma del genere non possa essere utilizzata come fonte di numeri pseudocasuali, poich\u00e9 \u00e8 indeterminata e, quindi, facilmente suscettibile a manipolazioni da parte di un oracolo.<\/p>\n

<\/p>\n

Tuttavia, come si \u00e8 scoperto, \u00e8 possibile renderla deterministica.<\/p>\n

<\/p>\n

Avevo grandi speranze in una funzione casuale verificabile (VRF)<\/a><\/noindex>, ma dopo aver esaminato la teoria, ho dovuto rinunciare a questa opzione. Sebbene la VRF offra una versione deterministica della firma e della sua prova, nell'algoritmo c'\u00e8 un punto strano che apre un buco nero per le manipolazioni da parte dell'oracolo. In particolare, durante il 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 nel contempo tenere un database delle corrispondenze tra k e i dati firmati, per poter sempre ricalcolare correttamente il risultato dal punto di vista del VRF. Se vedete un'estrazione basata su VRF senza rivelare la chiave privata, potete dibattere: sottolineare la necessit\u00e0 di rivelare la chiave oppure 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 e ottenuto il supporto degli analisti locali, \u00e8 nata la schematizzazione del funzionamento 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 \u00e8 risultato piuttosto semplice; per ottenere determinismo \u00e8 necessario fissare il valore di R prima che il messaggio da firmare venga generato. Se R \u00e8 fisso ed \u00e8 parte del messaggio da firmare, questo garantisce ulteriormente che R sia fissato nel messaggio stesso. Il valore di S \u00e8 univocamente determinato dal messaggio dell'utente e, di conseguenza, pu\u00f2 essere utilizzato come sorgente per numeri pseudocasuali.<\/p>\n

<\/p>\n

In questo schema, non importa come venga fissato R; rimane sotto la responsabilit\u00e0 dell'oracolo. \u00c8 importante che S sia univocamente definito 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 fisso, si noti che R riutilizzato<\/a><\/noindex> nella firma di messaggi diversi rivela univocamente la chiave privata nello schema EdDSA. Per il proprietario dell'oracolo, \u00e8 estremamente importante escludere la possibilit\u00e0 di riutilizzare R per firmare messaggi diversi dell'utente. Ci\u00f2 significa che, in qualsiasi manovra o collusione, l'oracolo correr\u00e0 sempre il rischio di perdere la propria chiave privata.<\/p>\n

<\/p>\n

In sintesi, l'oracolo deve fornire agli utenti due funzioni: l'inizializzazione, che registra il valore R, e la firma, che restituisce il valore S. La coppia R, S rappresenta una firma standard verificabile del messaggio utente contenente un valore R fisso e dati casuali dell'utente.<\/p>\n

<\/p>\n

Si pu\u00f2 obiettare che questo schema per la blockchain non \u00e8 altro che un comune schema commit-rivelazione<\/a><\/noindex>. In effetti, s\u00ec, \u00e8 proprio cos\u00ec. Ma ci sono alcuni punti da considerare. Innanzitutto, l'oracolo lavora sempre con la stessa chiave in tutte le operazioni, il che \u00e8 utile nei contratti. In secondo luogo, c'\u00e8 il rischio di perdita della chiave privata da parte dell'oracolo in caso di comportamento non corretto; ad esempio, se l'oracolo consente di effettuare campionamenti del risultato, bastano solo due campionamenti per scoprire la chiave privata e ottenere accesso completo al portafoglio. In terzo luogo, una firma nativamente verificabile sulla blockchain, che \u00e8 la fonte di casualit\u00e0, \u00e8 un'idea elegante.<\/p>\n

<\/p>\n

Per sei mesi l'idea di implementazione \u00e8 rimasta nella mia testa, finch\u00e9 non \u00e8 finalmente 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 andare avanti!<\/p>\n

<\/p>\n

Implementazione<\/h1>\n

<\/p>\n

Quindi, in questo progetto VECRO \u00e8 stato realizzato<\/a><\/noindex> sulla blockchain di Waves in modalit\u00e0 richiesta-risposta utilizzando transazioni di trasferimento tra l'utente e l'oracolo. A tale proposito, \u00e8 stato installato nello spazio dell'oracolo uno script che controlla il funzionamento in stretta conformit\u00e0 con la logica descritta sopra. Le transazioni dell'oracolo vengono verificate ripristinando l'intera catena di interazioni con l'utente. Nella verifica del valore finale sono coinvolte tutte e quattro le transazioni, il contratto intelligente le incastra in un rigoroso filo di controllo, verificando passo dopo passo tutti i valori e non lasciando spazio per eventuali manipolazioni.<\/p>\n

<\/p>\n

Ancora una volta, per essere chiaro. L'oracolo non opera semplicemente seguendo lo schema proposto. Il suo funzionamento \u00e8 completamente controllato a livello di blockchain da un contratto intelligente bloccante<\/a><\/noindex>. Un passo da iguino, e la transazione semplicemente non andr\u00e0 a buon fine. Quindi, se la transazione \u00e8 entrata nella blockchain, l'utente non deve nemmeno controllare nulla, poich\u00e9 \u00e8 gi\u00e0 stata verificata da centinaia di nodi della rete.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n