Introduzione

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Come nel caso del concetto di cifratura assolutamente resistente in crittografia, i veri protocolli di "Publicly Verifiable Random Beacon" (di seguito PVRB) cercano solo di avvicinarsi il più possibile allo schema ideale, poiché nelle reti reali non è applicabile in forma pura: bisogna accordarsi su un solo bit, ci devono essere molti round e tutti i messaggi devono essere estremamente veloci e sempre consegnati. Ovviamente, nelle reti reali non è così. Pertanto, nella progettazione di PVRB per compiti specifici nei moderni blockchain, oltre all'impossibilità di controllare il random ottenuto e alla crittografia resistente, sorgono molte problematiche puramente architettoniche e tecniche.

La blockchain rappresenta per PVRB essenzialmente un ambiente di comunicazione, in cui i messaggi corrispondono a transazioni. Questo consente di astrarsi parzialmente dai problemi di rete, dalla mancata consegna dei messaggi, dai problemi con il software intermedio: tutti questi rischi sono assunti da una rete decentralizzata, e il suo principale valore per PVRB è l'impossibilità di revocare o alterare una transazione già inviata. Questo impedisce ai partecipanti di disertare il protocollo, a meno che non abbiano condotto con successo un attacco al consenso. Tale livello di sicurezza è accettabile, perciò PVRB deve essere resiliente a collusioni tra partecipanti allo stesso modo della catena principale della blockchain. Inoltre, ciò implica che PVRB debba essere parte del consenso, se la rete ha concordato sulla catena principale dei blocchi, deve anche convenire su un unico risultato randomico onesto. In alternativa, PVRB può essere semplicemente un protocollo autonomo, implementato tramite smart contract, operante in modo asincrono rispetto alla blockchain e ai blocchi. Entrambi gli approcci presentano vantaggi e svantaggi, e la scelta tra essi è estremamente non banale.

Due modi per implementare PVRB

Descriviamo in dettaglio due varianti di implementazione del PVRB: la versione standalone, che funziona utilizzando un contratto intelligente indipendente dalla blockchain, e la versione integrata nel consenso, incorporata nel protocollo attraverso il quale la rete concorda sulla catena di blocchi e le transazioni incluse. In tutti i casi mi riferirò ai motori blockchain popolari: Ethereum, EOS e altri simili per modalità di distribuzione e elaborazione dei contratti intelligenti.

Contratto standalone

In questa variante, il PVRB è un contratto intelligente che accetta transazioni da random-producer (di seguito RP), le elabora, combina i risultati e, di conseguenza, arriva a un certo valore che può essere ottenuto da qualsiasi utente di questo contratto. Questo valore potrebbe non essere memorizzato direttamente nel contratto, ma essere rappresentato solo da dati dai quali è possibile estrarre deterministicamente un unico valore di risultato casuale. In questo schema, RP sono gli utenti della blockchain, e chiunque può partecipare al processo di generazione.

La variante con contratto standalone è vantaggiosa per:

portabilità (i contratti possono essere trasferiti da una blockchain all'altra)
semplicità di implementazione e test (i contratti sono facili da scrivere e testare)
comodità nell'implementazione di schemi economici (facile creare il proprio token, la cui logica serve agli obiettivi di PVRB)
possibilità di avvio in blockchain già funzionanti

Ha anche dei difetti:

forti limitazioni sulle risorse durante i calcoli, volume delle transazioni e storage (in termini semplici cpu/mem/io)
limitazioni sulle operazioni all'interno del contratto (non tutte le istruzioni sono disponibili, è complicato collegare librerie esterne)
impossibilità di organizzare scambi di messaggi più velocemente dell'inclusione delle transazioni nella blockchain

Questa opzione è adatta per l'implementazione di PVRB, che deve essere avviato in una rete esistente, senza contenere crittografia complessa e senza richiedere molte interazioni.

Integrato nel consenso

In questa variante, PVRB è implementato nel codice del nodo blockchain, integrato o funziona parallelamente allo scambio di messaggi tra i nodi della blockchain. I risultati del protocollo vengono registrati direttamente nei blocchi generati, mentre i messaggi del protocollo vengono inviati tramite una rete p2p tra i nodi. Poiché il protocollo produce numeri che devono essere registrati nei blocchi, la rete deve raggiungere un consenso su di essi. Ciò significa che i messaggi PVRB, proprio come le transazioni, devono essere convalidati dai nodi ed essere inclusi nei blocchi, in modo che ogni partecipante alla rete possa validare il rispetto del protocollo PVRB. Questo ci porta automaticamente a una soluzione ovvia: se la rete raggiunge un consenso riguardo ai blocchi e alle transazioni in essi, allora PVRB deve far parte del consenso, e non essere un protocollo autonomo. Altrimenti, potrebbe verificarsi una situazione in cui un blocco è valido dal punto di vista del consenso, ma il protocollo PVRB non è stato rispettato, e dal punto di vista di PVRB il blocco non può essere accettato. Quindi, se viene scelto il modo “consensus-integrated”, PVRB diventa una parte importante del consenso.

Nel descrivere le implementazioni PVRB a livello di consenso nella rete, non si possono trascurare le questioni di finalità. La finalità è un meccanismo utilizzato nei consensi deterministici che fissa un blocco (e la catena che lo porta) come definitivo, il quale non verrà mai scartato, anche se compare un fork parallelo. Ad esempio, in Bitcoin questo meccanismo non esiste: se viene pubblicata una catena con una maggiore difficoltà, essa sostituirà qualsiasi catena meno complessa, indipendentemente dalla lunghezza delle catene. In EOS, invece, i cosiddetti Last Irreversible Blocks sono considerati finali, e si verificano in media ogni 432 blocchi (12*21 + 12*15, pre-voto + pre-impegno). Questo processo consiste fondamentalmente nell'attendere 2/3 delle firme dei produttori di blocchi (di seguito BP). Quando si presentano fork più vecchi dell'ultimo LIB, essi vengono semplicemente scartati. Questo meccanismo consente di affermare con certezza che una transazione è stata inclusa nella blockchain e non sarà mai retrocessa, indipendentemente dalle risorse di cui dispone l'attaccante. Inoltre, i blocchi finali sono quelli firmati da 2/3 dei BP in Hyperledger, Tendermint e altri consensi basati su pBFT. Inoltre, il protocollo per garantire la finalità ha senso da realizzare come un'estensione del consenso, poiché può funzionare in modo asincrono con la produzione e la pubblicazione dei blocchi. Ecco un buon articolo sulla finalità in Ethereum.

La finalità è estremamente importante per gli utenti, che senza di essa possono diventare vittime di un attacco di “double spend”, quando il BP “ritiene” i blocchi e li pubblica dopo che la rete ha “visto” una buona transazione. Se non c'è finalità, la fork pubblicata sostituisce il blocco con la transazione “buona” con un altro, della “cattiva” fork, nella quale gli stessi fondi vengono trasferiti all'indirizzo dell'attaccante. Nel caso di PVRB, i requisiti per la finalità sono ulteriormente inaspriti, poiché la costruzione di fork per il PVRB significa che l'attaccante può preparare più opzioni di casualità per pubblicare quella più vantaggiosa per lui, limitando il tempo possibile per l'attacco — una buona soluzione.

Pertanto, la soluzione migliore è combinare PVRB e finalità in un unico protocollo — così un blocco finalizzato = una casualità finalizzata, ed è proprio ciò che si doveva ottenere. Ora i giocatori riceveranno una casualità garantita in N secondi e possono essere certi che non sia possibile annullarla o ripetere il gioco.

L'opzione con il consensus-integrated è buona:

la possibilità di implementazione asincrona rispetto alla produzione dei blocchi: i blocchi vengono prodotti come al solito, ma parallelamente può funzionare il protocollo PVRB, che genera casualità non per ogni blocco
la possibilità di implementare anche criptografia pesante, senza le restrizioni imposte dai contratti intelligenti
la possibilità di organizzare scambi di messaggi più velocemente di quanto le transazioni vengano incluse nella blockchain; ad esempio, parte del protocollo può funzionare tra i nodi senza diffondere i messaggi attraverso la rete

Ha anche dei difetti:

difficoltà durante il testing e lo sviluppo: sarà necessario emulare errori di rete, nodi che scompaiono, hard fork della rete
errori nell'implementazione richiedono un hard fork della rete

Entrambi i metodi di implementazione del PVRB hanno diritto di esistere, ma l'implementazione su smart contract nei blockchain moderni è comunque piuttosto limitata nelle risorse computazionali, e qualsiasi passaggio a crittografie avanzate è spesso semplicemente impossibile. E ci servirà una crittografia solida, come dimostreremo più avanti. Anche se questo problema è chiaramente temporaneo, la crittografia robusta nei contratti è necessaria per risolvere molteplici sfide, e gradualmente sta emergendo (ad esempio, i contratti sistemici per zkSNARKs in Ethereum).

Un blockchain che garantisce un canale di comunicazione trasparente e affidabile per il protocollo non lo fa gratuitamente. Qualsiasi protocollo decentralizzato deve considerare la possibilità di attacchi Sybil; qualsiasi azione può essere effettuata congiuntamente da molti account, quindi è fondamentale considerare le capacità degli attaccanti di creare un numero arbitrario di partecipanti al protocollo in collusione.

PVRB e variabili di blocco.

Non ho mentito quando ho detto che un buon PVRB, testato da molte applicazioni di gioco, non è stato ancora implementato nelle blockchain. Ma com'è possibile che ci siano così tante applicazioni di gioco su Ethereum ed EOS? Questo mi sorprende tanto quanto voi; ma da dove provengono così tanti "random" "resistenti" in un ambiente completamente deterministico?

Il modo preferito per generare casualità nella blockchain è prendere qualche informazione "imprevedibile" da un blocco e basarla su di essa per creare casualità; basta fare l'hash di uno o più valori. È un buon articolo che tratta i problemi di tali schemi. quiSi può prendere uno qualsiasi dei valori "imprevedibili" nel blocco, ad esempio l'hash del blocco, il numero di transazioni, la difficoltà di rete e altri valori ignoti in anticipo. Dopo, si fa l'hash di questi valori, uno o più, e, in teoria, dovrebbe risultare un vero casuale. Si potrebbe anche aggiungere nel whitepaper che il vostro schema è "post-quantum secure" (dato che esistono funzioni hash resistenti ai quanti :)).

Ma purtroppo anche gli hash post-quantum secure non sono sufficienti. Il segreto risiede nei requisiti per il PVRB, che ricordo dalla precedente articolo:

Il risultato deve avere una distribuzione dimostrabilmente uniforme, basata su crittografia dimostrabilmente robusta.
Nessuno dei bit del risultato può essere controllato. Di conseguenza, il risultato non può essere previsto in anticipo.
Non è possibile sabotare il protocollo di generazione non partecipando al protocollo o sovraccaricando la rete con messaggi malevoli.
Tutto quanto sopra deve essere resistente a collusioni di un numero accettabile di partecipanti disonesti al protocollo (ad esempio, 1/3 dei partecipanti).

In questo caso è rispettato solo il requisito 1 e non il 2. Hashando valori imprevedibili dal blocco, otteniamo una distribuzione uniforme e buoni esiti casuali. Tuttavia, il BP ha almeno la possibilità di 'pubblicare il blocco o meno'. In questo modo, il BP può almeno scegliere tra DUE varianti casuali: 'la propria' e quella che risulterebbe se a pubblicare il blocco fosse qualcun altro. Il BP può anticipare 'cosa accadrebbe' se pubblicasse il blocco e semplicemente decidere se farlo o meno. Così, giocando ad esempio a 'pari-dispari' o 'rosso/nero' alla roulette, potrebbe pubblicare il blocco solo se vede una vincita. Questo rende anche non funzionale la strategia di utilizzo di un hash del blocco 'dal futuro'. In questo caso si dice che 'verrà usato un random che deriva dall'hashing dei dati attuali e dall'hash del futuro blocco alla profondità, ad esempio, N + 42, dove N è l'altezza attuale del blocco. Questo rinforza leggermente lo schema, ma consente comunque al BP, anche se in futuro, di scegliere se trattenere il blocco o pubblicarlo.

Il software BP in questo caso si complica, ma non eccessivamente. Durante la validazione e l'inclusione delle transazioni nel blocco, viene effettuato un controllo rapido per vedere se ci sarà una vincita e, forse, la selezione di alcuni parametri della transazione per ottenere un'alta probabilità di vincita. Tuttavia, catturare un BP intelligente con queste manovre è praticamente impossibile, poiché si possono utilizzare nuovi indirizzi ogni volta, vincendo poco a poco, senza destare sospetti.

Quindi, i metodi che utilizzano informazioni dal blocco non possono essere considerati una soluzione universale per l'implementazione del PVRB. In una versione limitata, con restrizioni sulle dimensioni delle scommesse, sul numero di giocatori e/o registrazione KYC (per evitare che un solo giocatore possa utilizzare più indirizzi), questi schemi possono funzionare per piccoli giochi, ma non oltre.

PVRB e commit-reveal.

Va bene, grazie all'hashing e almeno alla relativa imprevedibilità dell'hash del blocco e delle altre variabili. Se si riesce a risolvere il problema del front-running dei miner, dovrebbe risultare qualcosa di migliore. Aggiungiamo gli utenti a questo schema — così possono influenzare il random: qualsiasi operatore del supporto tecnico vi dirà che la cosa più casuale nei sistemi IT sono le azioni degli utenti 🙂

Uno schema naïf in cui gli utenti inviano semplicemente numeri casuali e il risultato viene calcolato come, ad esempio, l'hash della loro somma, non è utile. In questo caso, l'ultimo giocatore potrebbe controllare il risultato scegliendo il proprio numero casuale. Per questo motivo, si utilizza un patron molto comune chiamato commit-reveal. Gli partecipanti inviano prima gli hash dei loro numeri casuali (commits) e poi rivelano i numeri stessi (reveals). La fase di 'reveal' inizia solo dopo che gli hash necessari sono stati raccolti, quindi i partecipanti possono inviare esattamente il numero casuale di cui hanno precedentemente inviato l'hash. Adesso mettiamo insieme tutto questo con i parametri del blocco, preferibilmente presi dal futuro (il numero casuale potrà essere conosciuto solo in uno dei futuri blocchi), ed ecco fatto — il numero casuale è pronto! Ora ogni giocatore influisce sul numero casuale risultante e può 'vincere' contro un BP maligno, sovrapponendo il suo numero casuale sconosciuto in anticipo... Si può anche aggiungere una protezione contro il sabotaggio del protocollo in fase di reveal — semplicemente richiedendo, al momento del commit, di allegare una certa somma alla transazione — un deposito a garanzia, che verrà restituito solo durante la procedura di reveal. In questo caso, effettuare un commit senza poi fare un reveal non sarebbe vantaggioso.

È stata una buona prova e schemi simili esistono anche nei DApp di gioco, ma purtroppo non è ancora sufficiente. Ora il risultato può essere influenzato non solo dal miner, ma anche da qualsiasi partecipante al protocollo. Il valore stesso può ancora essere controllato, con una minore variabilità e a pagamento, ma, come nel caso del miner, se i risultati dell'estrazione sono più preziosi della quota per partecipare al protocollo PVRB, allora il random-producer (RP) può decidere se fare il reveal e può ancora scegliere tra almeno due opzioni di casualità.
In compenso, è stata introdotta la possibilità di punire coloro che fanno commit e non effettuano il reveal, e questo schema sarà utile. La sua semplicità è un grande vantaggio: protocolli più complessi richiedono calcoli molto più potenti.

PVRB e firme deterministiche.

C'è un altro modo per costringere RP a fornire un numero pseudo-casuale su cui non potrà esercitare alcuna influenza, se gli si fornisce un "modello": questa è una firma deterministica. Una firma come quella è, ad esempio, RSA, e non è ECS. Se RP ha una coppia di chiavi: RSA ed EСC, e firma un certo valore con la sua chiave privata, nel caso di RSA otterrà UNA E SOLA FIRMA, mentre nel caso di ECS può generare un numero qualsiasi di firme valide diverse. Questo accade perché nella creazione di una firma ECS viene utilizzato un numero casuale scelto dall'autore della firma, e può essere scelto in qualsiasi modo, dando all'autore della firma la possibilità di scegliere tra diverse firme. Nel caso di RSA: "un valore di input" + "una coppia di chiavi" = "una firma". Non è possibile prevedere quale sarà la firma di un altro RP, quindi PVRB con firme deterministiche può essere organizzato attraverso la combinazione delle firme RSA di più partecipanti che hanno firmato lo stesso valore. Ad esempio, il precedente casuale. In questo schema si risparmiano molte risorse, poiché le firme fungono sia da conferma del corretto comportamento secondo il protocollo, sia da fonte di casualità.

Tuttavia, anche con le firme determinate, lo schema è ancora vulnerabile al problema del 'last actor'. L'ultimo partecipante può ancora decidere se pubblicare la propria firma o meno, controllando così il risultato. È possibile migliorare lo schema, aggiungendo hash dei blocchi, effettuando turni in modo che il risultato non possa essere previsto in anticipo, ma tutte queste tecniche, anche considerando numerosi miglioramenti, lasciano comunque irrisolta la questione dell'influenza di un singolo partecipante sul risultato collettivo in un ambiente non fidato e possono funzionare solo in condizioni di vincoli economici e temporali. Inoltre, la dimensione delle chiavi RSA (1024 e 2048 bit) è piuttosto grande, e la dimensione per le transazioni blockchain è un parametro estremamente importante. Sembra che non sarà facile risolvere il problema in modo semplice, andiamo oltre.

Nella crittografia esistono schemi che possono consentire a una rete di accordarsi su un unico valore PVRB, rimanendo al contempo resistenti a qualsiasi azione malevola da parte di alcuni partecipanti. Un protocollo utile da conoscere è il piano di divisione del segreto di Shamir. Questo protocollo serve a dividere un segreto (ad esempio, una chiave segreta) in più parti e distribuirle a N partecipanti. Il segreto è distribuito in modo tale che per il suo recupero siano sufficienti M parti su N, e queste possono essere qualsiasi M parti. In modo semplice, immaginando un grafico di una funzione sconosciuta, i partecipanti si scambiano punti sul grafico e, dopo aver ottenuto M punti, l'intera funzione può essere ricostruita.
Una buona spiegazione è fornita in wiki ed è utile sperimentare praticamente per comprendere meglio il protocollo su demo pagina.

Se lo schema FSSS (Fiat-Shamir Secret Sharing) fosse applicabile in modo diretto, sarebbe un PVRB indistruttibile. Nella sua forma più semplice, il protocollo potrebbe apparire così:

Ogni partecipante genera il proprio random e distribuisce le quote agli altri partecipanti.
Ogni partecipante svela la propria parte dei segreti degli altri partecipanti
Se per un partecipante si accumulano più di M shares, è possibile calcolare il numero di quel partecipante, e sarà univoco, indipendentemente dal gruppo di partecipanti svelati
La combinazione di random svelati è il PVRB ricercato

Qui un singolo partecipante non influisce già sui risultati del protocollo, tranne nei casi in cui il raggiungimento della soglia di svelamento del random dipende esclusivamente da lui. Pertanto, questo protocollo, con la giusta quota di partecipanti che seguono il protocollo e RP disponibili, funziona soddisfacendo i requisiti di resistenza crittografica, ed è resistente al problema del “last actor”.

Questo potrebbe essere un'opzione ideale, questo schema PVRB basato sul secret sharing di Fiat-Shamir è descritto, ad esempio, in questo un articolo. Ma, come detto sopra, se si cerca di applicarlo direttamente nella blockchain, emergono già delle limitazioni tecniche. Ecco un esempio di implementazione del protocollo in un smart contract EOS e la sua parte più importante: la verifica della share pubblicata dal partecipante: codice. Dal codice si evince che la validazione della prova richiede diversi prodotti scalari e vengono utilizzati numeri molto grandi. È importante comprendere che nei blockchain la verifica avviene nel momento in cui il produttore del blocco elabora la transazione, e ogni partecipante deve poter controllare facilmente la correttezza del protocollo; quindi, le esigenze di velocità della funzione di verifica sono molto rigorose. In questa versione, si è rivelata non funzionante, poiché la verifica non rientrava nel limite sulla transazione (0,5 secondi).

L'efficienza della verifica è uno dei requisiti più importanti per l'uso di qualsiasi schema crittografico avanzato nel blockchain. La creazione delle prove, la preparazione dei messaggi: queste procedure possono essere eseguite off-chain e realizzate su computer ad alta prestazione, ma non si potrà eludere la verifica — questo è un altro requisito fondamentale per il PVRB.

PVRB e firme soglia

Incontrando il schema del secret sharing, abbiamo scoperto una vera e propria classe di protocolli legati alla parola chiave “threshold”. Quando per rivelare alcune informazioni è necessaria la partecipazione di M partecipanti onesti su N, e l'insieme di partecipanti onesti può essere un qualsiasi sottoinsieme di N, si parla di schemi “threshold”. Questi permettono di affrontare il problema del “last actor”; ora, se un attaccante non rivela la sua parte del segreto, un altro partecipante onesto lo farà al suo posto. Questi schemi consentono di concordare su un unico valore anche in caso di sabotaggio del protocollo da parte di alcuni partecipanti.

La combinazione di firme deterministiche e schemi threshold ha permesso di sviluppare uno schema molto pratico e promettente per l'implementazione del PVRB — le firme threshold deterministiche. Ecco articolo sugli usi vari delle firme threshold, ecco un altro buon longread da Dash.

L'ultimo articolo descrive le firme BLS (BLS sta per Boneh-Lynn-Shacham, ecco Articolo ), che possiedono una qualità molto importante e estremamente utile per i programmatori: le chiavi pubbliche, segrete e le firme BLS possono essere combinate tra loro tramite semplici operazioni matematiche, mantenendo al contempo la validità delle combinazioni come chiavi e firme, consentendo di aggregare facilmente molte firme in una e molte chiavi pubbliche in una sola. Inoltre, sono deterministiche e producono lo stesso risultato per gli stessi dati di input. Grazie a questa caratteristica, le combinazioni delle firme BLS sono esse stesse chiavi valide, permettendo di realizzare una soluzione in cui M su N partecipanti generano una sola firma, che è determinata, verificabile pubblicamente e imprevedibile fino a quando non viene rivelata dal M-esimo partecipante.

Nello schema delle firme threshold BLS, ogni partecipante firma qualcosa (ad esempio, il precedente random) utilizzando BLS, e la firma threshold totale è il random ricercato. Le proprietà crittografiche delle firme BLS soddisfano i requisiti di qualità del random, la parte threshold protegge da un attore finale 'last-actor', mentre la combinabilità unica delle chiavi consente di implementare molti altri algoritmi interessanti che permettono, ad esempio, di aggregare efficacemente i messaggi del protocollo.

Quindi, se stai costruendo un PVRB nel tuo blockchain, è molto probabile che arriverai allo schema delle firme threshold BLS, già utilizzato da diversi progetti. Ad esempio, DFinity (qui un benchmark che implementa lo schema, e qui un esempio di implementazione di verifiable secret sharing), oppure Keep.network (ecco il loro random beacon yellowpaper, ecco esempio il contratto smart che supporta il protocollo).

Implementazione del PVRB

Purtroppo, non vediamo ancora un protocollo pronto, implementato nelle blockchain PVRB, che abbia dimostrato la sua sicurezza e robustezza. Anche se i protocolli sono pronti, applicarli tecnicamente alle soluzioni esistenti non è semplice. Per i sistemi centralizzati, PVRB non ha senso, mentre i sistemi decentralizzati sono rigorosamente limitati in tutte le risorse computazionali: CPU, memoria, storage, I/O. Progettare PVRB implica combinare diversi protocolli per forgiarne uno che soddisfi tutti i requisiti per essere utilizzato in almeno una blockchain funzionante. Un protocollo calcola in modo più efficiente, ma richiede più messaggi tra RP, mentre un altro ne richiede molto pochi, ma la creazione della prova può richiedere decine di minuti o ore.

Elencherò i fattori che è necessario considerare nella scelta di un PVRB di alta qualità:

Resistenza crittografica. Il tuo PVRB deve essere assolutamente unbiasable, senza possibilità di controllare un singolo bit. In alcune configurazioni questo non è il caso, quindi chiama un crittografo
Problema del "last actor". Il tuo PVRB deve essere resistente agli attacchi, quando un attaccante che controlla uno o più RP può scegliere tra due possibili esiti.
Problema di sabotaggio del protocollo. Il tuo PVRB deve essere resistente agli attacchi, quando un attaccante che controlla uno o più RP decide se essere casuale o meno e può garantire, con certezza o con una certa probabilità, di influenzare questo aspetto.
Problema del numero di messaggi. I tuoi RP devono inviare al blockchain il minimo indispensabile di messaggi e massimizzare l'evitamento di azioni sincrone come situazioni in cui “ho inviato alcune informazioni, attendo una risposta da un partecipante specifico”. Nelle reti p2p, soprattutto quando geograficamente disperse, non ci si deve aspettare una risposta rapida.
Problema della complessità computazionale. La verifica di qualsiasi fase del PVRB on-chain deve essere estremamente semplice, poiché viene eseguita da tutti i nodi completi della rete. Se l'implementazione avviene tramite un contratto intelligente, i requisiti di velocità sono molto severi.
Problema di accessibilità e liveness. Il tuo PVRB deve mirare a essere resistente a situazioni in cui parte della rete diventa inaccessibile per un certo periodo e alcuni RP smettono semplicemente di funzionare.
Problemi di trusted setup e distribuzione iniziale delle chiavi. Se il tuo PVRB utilizza il setup primario del protocollo, è una questione separata, ampia e seria. Ecco esempio. Se i partecipanti devono comunicarsi le proprie chiavi prima dell'inizio del protocollo, può essere problematico se la composizione dei partecipanti cambia
Problemi di sviluppo. La disponibilità di librerie nei linguaggi richiesti, la loro sicurezza e prestazioni, la loro pubblicità, test complessi e così via.

Ad esempio, il threshold BLS ha un problema significativo: prima di iniziare a lavorare, i partecipanti devono necessariamente scambiarsi le chiavi, organizzando un gruppo all'interno del quale opererà il threshold. Ciò significa che è necessario attendere almeno un round di scambi in una rete decentralizzata e, considerando che il random generato, per esempio, è necessario nei giochi praticamente in tempo reale, questo implica che il sabotaggio del protocollo è possibile in questa fase, facendo così perdere i vantaggi dello schema threshold. Questo problema è più semplice rispetto ai precedenti, ma richiede comunque lo sviluppo di una procedura separata per la formazione dei gruppi threshold, che dovrà essere economicamente protetta, attraverso depositi e il ritiro di fondi (slashing) ai partecipanti che non seguono il protocollo. Inoltre, la verifica BLS con un livello di sicurezza accettabile semplicemente non rientra, ad esempio, in una transazione standard su EOS o Ethereum — semplicemente non c'è tempo sufficiente per la verifica. Il codice dei contratti è WebAssembly o EVM, eseguito da una macchina virtuale. Le funzioni crittografiche non sono implementate nativamente (ancora) e funzionano decine di volte più lentamente rispetto alle librerie crittografiche normali. Molti protocolli non soddisfano i requisiti semplicemente in base alla dimensione delle chiavi, ad esempio 1024 e 2048 bit per RSA, da 4 a 8 volte di più rispetto alla firma standard di una transazione in Bitcoin ed Ethereum.

Il ruolo e la disponibilità di implementazioni in diversi linguaggi di programmazione è cruciale — ce ne sono pochi, specialmente per i nuovi protocolli. L'integrazione nel consenso richiede di scrivere il protocollo nel linguaggio della piattaforma, quindi sarà necessario cercare codice in Go per geth, in Rust per Parity, in C++ per EOS. Per quanto riguarda JavaScript, è da ricercare da tutti, e poiché JavaScript e crittografia non sono esattamente amici intimi, WebAssembly sarà d'aiuto, poiché ormai si propone sicuramente come il prossimo importante standard di Internet.

Conclusione

Spero che in precedenza articolo sia riuscito a convincervi che la generazione di numeri casuali sulla blockchain è critica per molti aspetti della vita delle reti decentralizzate, e con questo articolo ho mostrato che questo compito è estremamente ambizioso e complesso, ma buone soluzioni già esistono. In generale, il design finale del protocollo è possibile solo dopo aver effettuato test massivi che considerano tutti gli aspetti, dalla fase di setup all'emulazione dei guasti, quindi è improbabile che troviate ricette pronte nei whitepaper dei team e negli articoli, e noi nei prossimi uno o due anni sicuramente non ci avventureremo a scrivere “fate così, è sicuramente corretto”.

Nel frattempo, per il nostro PVRB nella blockchain in fase di sviluppo Haya, ci siamo concentrati sull'implementazione delle firme threshold BLS, con l'intenzione di realizzare PVRB a livello di consenso, poiché la verifica nei contratti smart con un livello di sicurezza accettabile è attualmente impossibile. È possibile che utilizziamo due schemi: inizialmente un costoso secret sharing per creare un random_seed a lungo termine, che utilizzeremo successivamente come base per una generazione casuale ad alta frequenza tramite firme threshold BLS determinate, ma potremmo limitarci a uno solo degli schemi. È difficile prevedere in anticipo quale sarà il protocollo, ma ciò che consola è che, come nella scienza, anche nelle sfide ingegneristiche un risultato negativo è pur sempre un risultato, e ogni nuovo tentativo di risolvere il problema rappresenta un ulteriore passo avanti per tutti coloro che si occupano di questa questione. Per soddisfare le esigenze aziendali, affrontiamo un compito altamente pratico: garantire alle applicazioni di gioco una fonte affidabile di entropia, e quindi dobbiamo prestare attenzione anche alla blockchain stessa, in particolare alle questioni relative alla finalità della catena e alla governance della rete.

Sebbene al momento non osserviamo un PVRB prolungato e comprovato nei blockchain, utilizzato per un tempo sufficiente a superare i test con applicazioni reali, audit multipli, carichi e, naturalmente, attacchi reali, il numero dei possibili percorsi conferma che una soluzione esiste e che uno di questi algoritmi risolverà finalmente il problema. Siamo felici di condividere i risultati e ringraziamo gli altri team che stanno affrontando questa questione per gli articoli e il codice che permettono agli ingegneri di non incappare due volte negli stessi errori.

Quindi, quando incontrate un programmatore che progetta un generatore di casualità decentralizzato, siate attenti e premurosi, offrendo supporto psicologico se necessario 🙂

Fonte: habr.com