Introduzione

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

Come nel caso del concetto di cifratura assolutamente resistente della crittografia, i protocolli reali "Publicly Verifiable Random Beacon" (di seguito PVRB) cercano solo di avvicinarsi il più possibile a uno schema ideale, poiché nelle reti reali non è applicabile in modo puro: è necessario accordarsi su un singolo bit, ci devono essere molti turni 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 blockchain moderni, oltre all'impossibilità di controllare il random ottenuto e alla resistenza crittografica, emergono anche molti problemi puramente architettonici e tecnici.

Il blockchain stesso funge essentially da ambiente di comunicazione per PVRB, in cui i messaggi = transazioni. Questo consente di astraersi parzialmente dai problemi di rete, dalla mancata consegna dei messaggi e dai problemi del software intermedio: tutti questi rischi vengono assunti dalla rete decentralizzata, e il suo valore principale per PVRB è l'impossibilità di revocare o danneggiare una transazione già inviata, il che non consente ai partecipanti di ritirarsi dal protocollo, a meno che non abbiano effettuato un attacco di successo al consenso. Tale livello di sicurezza è accettabile, quindi PVRB deve essere resistente ai collusioni dei partecipanti nella stessa misura della catena principale del blockchain. Inoltre, questo suggerisce che PVRB deve far parte del consenso, se la rete ha concordato sulla catena principale di blocchi, affinché possa concordare anche su un singolo random risultante onesto. Oppure, PVRB è semplicemente un protocollo standalone, implementato tramite contratto intelligente, che opera in modo asincrono rispetto al blockchain e ai blocchi. Entrambi i metodi hanno i loro vantaggi e svantaggi, e la scelta tra di essi è estremamente non banale.

Due modi di implementare PVRB

Descriviamo in dettaglio due varianti di implementazione di PVRB: la versione standalone, che funziona utilizzando un contratto intelligente indipendente dal blockchain, e la versione integrata nel consenso, secondo la quale la rete concorda sulla catena di blocchi e sulle transazioni incluse. In tutti i casi, terrò presente i popolari motori blockchain: Ethereum, EOS, e tutti quelli simili nel modo di ospitare e processare contratti intelligenti.

Contratto autonomo

In questa versione, PVRB rappresenta un contratto intelligente che accetta transazioni da random-producer (di seguito RP), le elabora, combina i risultati e, di conseguenza, giunge a un 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 da cui si può determinare in modo univoco un solo valore del risultato casuale. In questo schema, gli RP sono gli utenti della blockchain, e chiunque può essere coinvolto nel processo di generazione.

Questa opzione del contratto autonomo ha vantaggi:

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

Tuttavia, presenta anche degli svantaggi:

severe limitazioni sulle risorse durante i calcoli, volume delle transazioni e storage (in parole povere cpu/mem/io)
limitazioni sulle operazioni all'interno del contratto (non tutte le istruzioni sono disponibili, è difficile collegare librerie esterne)
impossibilità di organizzare la messaggistica più velocemente di quanto le transazioni vengano incluse nella blockchain

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

Consensus-integrato

In questa variante, PVRB è implementato nel codice del nodo blockchain, incorporato o funziona in parallelo con lo scambio di messaggi tra i nodi della blockchain. I risultati del protocollo vengono registrati direttamente nei blocchi generati e i messaggi del protocollo vengono inviati attraverso la 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, così come le transazioni, devono essere validati dai nodi e inclusi nei blocchi, affinché ogni partecipante alla rete possa validare il rispetto del protocollo PVRB. Questo ci porta automaticamente a una soluzione ovvia: se la rete concorda sul consenso riguardo al blocco e alle transazioni in esso, allora PVRB deve essere parte del consenso e non un protocollo separato. Altrimenti, si potrebbe verificare una situazione in cui un blocco è valido dal punto di vista del consenso, ma il protocollo PVRB non è rispettato, e dal punto di vista di PVRB il blocco non può essere accettato. Pertanto, se viene scelto il tipo "consensus-integrated", PVRB diventa una parte importante del consenso.

Descrivendo le implementazioni di PVRB a livello di consenso nella rete, non si possono in alcun modo trascurare le questioni della finalità. La finalità è un meccanismo utilizzato nei consensi deterministici, fissando un blocco (e la catena che lo conduce) che è finale e non sarà mai scartato, anche se compare un fork parallelo. Ad esempio, in Bitcoin non esiste tale meccanismo: se viene pubblicata una catena di maggiore difficoltà, essa sostituirà qualsiasi catena di minor complessità, indipendentemente dalla lunghezza delle catene. In EOS, ad esempio, i blocchi finali sono i cosiddetti Last Irreversible Blocks, che compaiono in media ogni 432 blocchi (12*21 + 12*15, pre-vote + pre-commit). Questo processo è essenzialmente una attesa di 2/3 delle firme dai block-producers (BP). Quando appaiono fork che sono più vecchi dell'ultimo LIB, vengono semplicemente scartati. Questo meccanismo consente di affermare con certezza che una transazione è inclusa nella blockchain e non sarà mai retrocessa, indipendentemente dalle risorse disponibili per un 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 farlo come sovrastruttura sopra il consenso, poiché può funzionare in modo asincrono con la produzione e la pubblicazione dei blocchi. su Habr. 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à, il fork pubblicato sostituisce il blocco con la transazione "buona" con un'altra, proveniente da un fork "cattivo", in cui gli stessi fondi vengono trasferiti all'indirizzo dell'attaccante. Nel caso del PVRB, i requisiti di finalità diventano ancora più severi, poiché la costruzione di fork per PVRB significa che l'attaccante può preparare diverse versioni casuali per pubblicare quella più vantaggiosa e limitare il tempo di possibile attacco — una buona soluzione.

Pertanto, la migliore opzione è combinare PVRB e finalità in un unico protocollo — così il blocco finalizzato = casualità finalizzata, e questo è esattamente ciò che doveva essere ottenuto. Ora i giocatori riceveranno una casualità garantita in N secondi e possono stare certi che non può essere annullata o ripetuta.

L'opzione con consenso integrato è buona:

con la possibilità di attuazione asincrona rispetto alla produzione di blocchi — i blocchi vengono prodotti normalmente, ma parallelamente a questo può funzionare il protocollo PVRB, che produce casualità non ad ogni blocco.
con la possibilità di implementare anche crittografie pesanti, senza le limitazioni imposte dai contratti smart.
con la possibilità di organizzare comunicazioni più rapide rispetto all'inclusione delle transazioni nella blockchain, ad esempio parte del protocollo può funzionare tra nodi senza diffondere messaggi in rete.

Tuttavia, presenta anche degli svantaggi:

difficoltà nella testing e nello sviluppo — sarà necessario emulare errori di rete, nodi disattivati, 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 nei contratti smart nelle blockchain moderne è comunque piuttosto limitata nelle risorse computazionali, e qualsiasi passaggio a una crittografia seria è spesso semplicemente impossibile. E una crittografia seria ci sarà necessaria, come verrà dimostrato in seguito. Sebbene questo problema sia chiaramente di natura temporanea, una crittografia seria nei contratti è necessaria per risolvere molti compiti e, gradualmente, sta emergendo (ad esempio, contratti di sistema per zkSNARKs in Ethereum).

La blockchain che garantisce un canale di comunicazione trasparente e sicuro per il protocollo non lo fa gratuitamente. Qualsiasi protocollo decentralizzato deve considerare la possibilità di attacchi Sybil; qualsiasi azione può essere realizzata da forze concordate di più account, quindi nella progettazione è necessario tener conto delle capacità degli attaccanti di creare un numero arbitrario di partecipanti al protocollo che agiscono in collusione.

PVRB e variabili del blocco.

Non mentivo quando dicevo che un buon PVRB, verificato da molte applicazioni di gioco, non è ancora stato implementato nelle blockchain. Da dove viene allora un tale numero di applicazioni di gioco su Ethereum ed EOS? Questo mi sorprende tanto quanto voi; come hanno fatto a trovare così tanti "random" "resistenti" in un ambiente completamente deterministico?

Il modo preferito per ottenere casualità nella blockchain è prendere qualche informazione "imprevedibile" dal blocco e basare su di essa la generazione di random, semplicemente hashando uno o più valori. Un buon articolo sui problemi di tali schemi. qui. Si può prendere uno dei valori "imprevedibili" nel blocco, come l'hash del blocco, il numero di transazioni, la difficoltà della rete e altri valori sconosciuti in anticipo. Poi hashare questi, uno o più, e, in teoria, dovrebbe produrre una vera casualità. Si potrebbe anche aggiungere nel whitepaper che il vostro schema è "post-quantum secure" (dato che esistono funzioni di hash resistenti ai quanti :)).

Ma anche gli hash post-quantum secure non sono sufficienti, ahimè. Il segreto è nei requisiti per il PVRB, ricordo i loro punti dalla precedente articolo:

Il risultato deve avere una distribuzione dimostrabilmente uniforme, cioè basata su crittografia dimostrabilmente sicura.
Non è possibile controllare alcun bit del risultato. Di conseguenza, il risultato non può essere previsto in anticipo.
Non è possibile sabotare il protocollo di generazione mediante l'astensione dal protocollo o sovraccaricando la rete con messaggi malevoli.
Tutto quanto sopra deve essere resistente a cospirazioni di un numero consentito di partecipanti disonesti al protocollo (ad esempio 1/3 dei partecipanti).

In questo caso viene rispettato solo il requisito 1 e non il 2. Hashando valori imprevedibili dal blocco, otteniamo una distribuzione uniforme e buoni risultati casuali. Ma il BP ha almeno la possibilità di "pubblicare il blocco o meno". In questo modo, il BP può almeno scegliere tra DUE varianti di casualità: "propria" e quella che si otterrebbe se il blocco fosse pubblicato da qualcuno altro. Il BP può anticipare "cosa succederà" se pubblica il blocco e semplicemente decide se farlo o meno. Ad esempio, giocando a "pari-dispari" o "rosso/nero" alla roulette, può pubblicare il blocco solo se vede un guadagno. Questo rende inefficace anche la strategia di utilizzo, come ad esempio l'hash del blocco "del futuro". In questo caso si dice che "verrà utilizzata la casualità ottenuta dall'hashing dei dati attuali e dall'hash del blocco futuro di altezza, ad esempio, N + 42, dove N è l'altezza attuale del blocco. Questo un po' rinforza lo schema, ma consente comunque al BP, anche se in futuro, di scegliere se trattenere il blocco o pubblicarlo.

Il software del BP in questo caso si complica, ma non troppo. Durante la convalida e l'inclusione della transazione nel blocco viene effettuato un rapido controllo per vedere se ci sarà un guadagno e, possibilmente, la regolazione di uno dei parametri della transazione per ottenere un'alta probabilità di vincita. Tuttavia, catturare un BP intelligente durante tali manovre è praticamente impossibile, poiché si possono utilizzare nuovi indirizzi ogni volta, vincendo poco alla volta senza suscitare sospetti.

Pertanto, i metodi che utilizzano informazioni dal blocco non sono adatti come implementazione universale del PVRB. In una variante limitata, con restrizioni sulle dimensioni delle scommesse, limiti sul numero di giocatori e/o registrazione KYC (per evitare che un singolo giocatore utilizzi più indirizzi), questi schemi possono funzionare per piccoli giochi, ma non oltre.

PVRB e commit-reveal.

Bene, grazie all'hashing e almeno alla relativa imprevedibilità dell'hash del blocco e di altre variabili. Se risolviamo il problema del front-running dei miner, dovrebbe uscire qualcosa di più efficace. Aggiungiamo a questo schema gli utenti — lasciamo che influenzino anche la casualità: qualsiasi membro del supporto tecnico ti dirà che la cosa più casuale nei sistemi IT sono le azioni degli utenti 🙂

Uno schema ingenuo, in cui gli utenti inviano semplicemente numeri casuali e il risultato viene calcolato come, ad esempio, l'hash della loro somma, non è adatto. In questo caso, l'ultimo giocatore può controllare il risultato scegliendo il proprio numero casuale. Pertanto, si utilizza un pattern ampiamente diffuso chiamato commit-reveal. I partecipanti inviano prima gli hash dei loro numeri casuali (commit) e poi rivelano i numeri stessi (reveal). La fase 'reveal' inizia solo dopo che sono stati raccolti i commit necessari, quindi i partecipanti possono inviare esattamente il numero casuale di cui hanno inviato in precedenza l'hash. Ora uniamo tutto ciò con i parametri del blocco, meglio se presi dal futuro (il numero casuale potrà essere conosciuto solo in uno dei blocchi futuri), ed ecco fatto: il numero casuale è pronto! Ora ogni giocatore influisce sul numero casuale risultante e può 'sconfiggere' un BP malizioso, sovrapponendo il proprio numero casuale, scelto in anticipo, a quello dell'altro... Inoltre, si potrebbe aggiungere una protezione contro il sabotaggio del protocollo durante la fase di reveal, richiedendo semplicemente di allegare una certa somma alla transazione al momento del commit — un deposito di garanzia, che verrà restituito solo durante la procedura di reveal. In questo caso, fare commit e non fare reveal non sarebbe vantaggioso.

È stata una buona tentativa, e tali schemi esistono anche nelle DApp di gioco, ma purtroppo non basta. Ora il risultato può essere influenzato non solo dal miner, ma anche da qualsiasi partecipante al protocollo. Si può ancora controllare il valore in sé, con una minore variabilità e dietro compenso, ma, come nel caso del miner, se i risultati del sorteggio valgono più della quota di partecipazione al protocollo PVRB, allora il random-producer (RP) può decidere se fare reveal e può comunque scegliere tra almeno due opzioni di numero casuale.
D'altro canto, è emersa la possibilità di punire coloro che fanno commit e non fanno reveal, e questo schema sarà comunque utile. La sua semplicità è un vantaggio significativo: protocolli più complessi richiedono calcoli molto più potenti.

PVRB e firme determinate.

C'è un altro modo per costringere l'RP a fornire un numero pseudo-casuale su cui non può influire, se gli viene fornito un “modello”: si tratta di una firma deterministica. Una firma del genere è, ad esempio, RSA, e non è ECS. Se l'RP ha una coppia di chiavi: RSA e ECC, e firma un certo valore con la sua chiave privata, in caso di RSA otterrà UNA E SOLA FIRMA, mentre nel caso di ECS può generare un numero qualsiasi di firme valide diverse. Questo succede perché nella creazione della firma ECS viene utilizzato un numero casuale scelto dal firmatario, e può essere scelto in qualsiasi modo, dando al firmatario 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 il PVRB con firme deterministiche può essere organizzato combinando le firme RSA di più partecipanti che hanno firmato lo stesso valore. Ad esempio: un precedente casuale. In questo schema, si risparmiano molte risorse, poiché le firme sono al contempo una conferma del comportamento corretto secondo il protocollo e una fonte di casualità.

Tuttavia, anche con le firme deterministiche, lo schema è ancora vulnerabile al problema dell'“ultimo attore”. L'ultimo partecipante può comunque decidere se pubblicare la propria firma o meno, controllando così il risultato. Si può migliorare lo schema, aggiungendo hash dei blocchi, creando turni, in modo che il risultato finale non possa essere previsto in anticipo, ma tutti questi accorgimenti, anche considerando molte modifiche, lasciano comunque irrisolto il problema dell'influenza di un partecipante sul risultato collettivo in un ambiente non fidato e possono funzionare solo in condizioni di limitazioni economiche e temporali. Inoltre, la dimensione delle chiavi RSA (1024 e 2048 bit) è piuttosto grande, mentre la dimensione per le transazioni blockchain è un parametro estremamente importante. Sembrerebbe che non sia possibile risolvere semplicemente il problema, andiamo avanti.

Nella crittografia esistono schemi che consentono a una rete di concordare un unico valore PVRB, e tali schemi sono resistenti a qualsiasi azione malevola da parte di alcuni partecipanti. Uno dei protocolli utili da conoscere è lo schema di condivisione del segreto di Shamir. Serve a suddividere un segreto (ad esempio una chiave segreta) in diverse parti e distribuirle a N partecipanti. Il segreto è distribuito in modo tale che per ripristinarlo sia sufficiente avere M parti su N, e queste possono essere qualsiasi M parti. In parole povere, avendo un grafico di una funzione sconosciuta, i partecipanti scambiano punti sul grafico e dopo aver ricevuto M punti, l'intera funzione può essere ricostruita.
Una buona spiegazione è fornita in wiki ed è utile giocarci praticamente, per mettere a fuoco il protocollo nella mente demo pagina.

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

Ogni partecipante genera un proprio random e distribuisce le shares agli altri partecipanti
Ogni partecipante rivela la propria parte dei segreti degli altri partecipanti
Se un partecipante accumula più di M shares, il numero di quel partecipante può essere calcolato ed sarà unico, indipendentemente dal set di partecipanti che hanno rivelato i loro segreti
La combinazione degli random rivelati è il PVRB cercato

In questo caso, un partecipante non influisce sui risultati del protocollo, eccetto nei casi in cui il raggiungimento della soglia di rivelazione del random dipenda esclusivamente da lui. Pertanto, questo protocollo, con la necessaria quota di partecipanti che seguono il protocollo e con RP disponibili, funziona realizzando i requisiti di robustezza crittografica ed è resistente al problema dell' "ultimo attore".

Questo potrebbe essere un'opzione ideale; questo schema PVRB basato sulla condivisione dei segreti di Fiat-Shamir è descritto, ad esempio, in questo un articolo. Ma, come già detto, tentare di applicarlo direttamente nella blockchain presenta già limitazioni tecniche. Ecco un esempio di implementazione di prova del protocollo in un contratto intelligente EOS e la sua parte più importante: la verifica della share pubblicata dal partecipante: codiceIl codice mostra che la validazione del proof richiede diverse moltiplicazioni scalari, e i numeri utilizzati sono molto grandi. È importante comprendere che nel blockchain la verifica avviene nel momento in cui il block-producer elabora la transazione, e qualsiasi partecipante deve poter verificare facilmente la correttezza del protocollo; pertanto, i requisiti per la velocità della funzione di verifica sono molto rigorosi. In questa variante, il metodo si è rivelato non funzionante, poiché la verifica non rientrava nel limite di tempo della transazione (0,5 secondi).

L'efficienza della verifica è uno dei requisiti più importanti per l'utilizzo di praticamente qualsiasi schema crittografico avanzato nel blockchain. La creazione di prove, la preparazione dei messaggi: queste procedure possono essere eseguite off-chain e su computer ad alte prestazioni, ma la verifica non può essere evitata: questo è un ulteriore importante requisito per il PVRB.

PVRB e firme threshold

Familiarizzando con lo schema del secret sharing, abbiamo aperto un'intera classe di protocolli uniti dalla parola chiave “threshold”. Quando per rivelare alcune informazioni è richiesta la partecipazione di M partecipanti onesti su N, e il gruppo di partecipanti onesti può essere un qualsiasi sottoinsieme di N, si parla di schemi “threshold”. Questi schemi permettono di affrontare il problema del “last actor”; ora, se l'attaccante non rivela la propria parte del segreto, un altro partecipante onesto lo farà. Questi schemi consentono di concordare un unico valore, anche in caso di sabotaggio del protocollo da parte di alcuni partecipanti.

La combinazione di firme deterministiche e schemi threshold ha portato allo sviluppo di uno schema molto conveniente e promettente per l'attuazione del PVRB: le firme threshold deterministiche. Ecco su Habr. sui vari utilizzi delle firme threshold, ecco un altro buon longread da Dash.

Nell'ultimo articolo si descrivono le firme BLS (BLS sta per Boneh-Lynn-Shacham, ecco L'articolo ), che presenta una qualità estremamente importante e molto conveniente per i programmatori — i chiavi pubbliche, segrete e le firme BLS possono essere combinate tra loro tramite semplici operazioni matematiche, rimanendo valide come chiavi e firme, permettendo di aggregare facilmente molte firme in una sola e molte chiavi pubbliche in una sola. Possiedono inoltre deterministicità e, per gli stessi dati in input, producono sempre lo stesso risultato. Grazie a questa qualità, le combinazioni delle firme BLS sono a loro volta chiavi valide, permettendo di realizzare un'opzione in cui M partecipanti su N producono una sola e unica firma, che è deterministica, verificabile pubblicamente e imprevedibile fino a quando non viene rivelata dal M-esimo partecipante.

Nello schema delle firme BLS con soglia, ogni partecipante firma qualcosa (ad esempio il precedente random) tramite BLS, e la firma complessiva con soglia è il random ricercato. Le proprietà crittografiche delle firme BLS soddisfano i requisiti di qualità del random, la parte di soglia protegge contro il “last-actor”, mentre la combinabilità unica delle chiavi consente di realizzare molti 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 tu arrivi a uno schema di firme BLS con soglia, già utilizzato da diversi progetti. Ad esempio, DFinity (qui benchmark che implementa lo schema, e qui esempio di implementazione della condivisione segreta verificabile), oppure Keep.network (ecco il loro random beacon yellowpaper, ma ecco un esempio smart contract che gestisce il protocollo).

Implementazione del PVRB

Sfortunatamente, finora non vediamo un protocollo PVRB implementato nelle blockchain che abbia dimostrato la sua sicurezza e robustezza. Anche se i protocolli stessi sono pronti, applicarli tecnicamente a soluzioni esistenti non è semplice. Per i sistemi centralizzati, il PVRB non ha senso, mentre i sistemi decentralizzati sono rigorosamente limitati in tutte le risorse computazionali: CPU, memoria, archiviazione, I/O. Progettare un PVRB significa combinare diversi protocolli per costruire qualcosa che soddisfi tutti i requisiti necessari a una qualsiasi blockchain praticabile. Un protocollo calcola in modo più efficiente, ma richiede più messaggi tra gli RP, mentre un altro ne richiede pochissimi, ma la creazione di una proof può richiedere decine di minuti o addirittura ore.

Elenco i fattori che dovrete considerare nella scelta di un PVRB di qualità:

Resistenza crittografica. Il vostro PVRB deve essere rigorosamente unbiasable, senza possibilità di controllo di un singolo bit. In alcune configurazioni questo non è così, quindi chiamate un crittografo.
Problema del “last actor”. Il vostro PVRB deve essere resistente ad attacchi in cui un attaccante, che controlla uno o più RP, può scegliere tra due possibili risultati.
Problema di sabotaggio del protocollo. Il vostro PVRB deve essere resistente ad attacchi in cui un attaccante, che controlla uno o più RP, decide se essere casuale o meno e può influenzare garantito, o con una certa probabilità, questa decisione.
Problema del numero di messaggi. I vostri RP devono inviare al blockchain il minor numero possibile di messaggi e massimizzare la prevenzione di azioni sincrone come le situazioni “ho inviato alcune informazioni, attendo una risposta da un partecipante specifico”. Nelle reti p2p, soprattutto quelle geograficamente distribuite, non si dovrebbe contare su una risposta veloce.
Problema della complessità computazionale. La verifica di qualsiasi fase del PVRB on-chain deve essere estremamente semplice, dato che viene eseguita da tutti i nodi completi della rete. Se l’implementazione viene effettuata tramite smart contract, i requisiti di velocità sono molto rigorosi.
Problema di disponibilità e liveness. Il vostro PVRB deve tendere a essere resistente a situazioni in cui parte della rete diventa non disponibile per un certo periodo e parte degli RP smette semplicemente di funzionare.
Problema del trusted setup e distribuzione iniziale delle chiavi. Se il tuo PVRB utilizza un set-up primario del protocollo, si tratta di una storia diversa e seria. Ecco un esempio. Se i partecipanti devono comunicarsi le loro chiavi prima di iniziare il protocollo, è anche un problema, specialmente se la composizione dei partecipanti cambia
Problemi di sviluppo. La disponibilità di librerie nelle lingue richieste, la loro sicurezza e prestazioni, la pubblicità, test complessi, ecc.

Ad esempio, il threshold delle firme BLS ha un problema sostanziale: prima di poter iniziare a lavorare, i partecipanti devono necessariamente scambiarsi le chiavi, organizzando un gruppo all'interno del quale lavorerà il threshold. Questo significa che è necessario attendere almeno un round di scambio in una rete decentralizzata e, considerando che il random generato, ad esempio, è necessario nei giochi, praticamente in tempo reale, questo implica che il sabotaggio del protocollo è possibile a questo punto, e i vantaggi del sistema threshold vengono persi. Questo problema è già più semplice dei precedenti, ma richiede comunque lo sviluppo di una procedura separata per la formazione dei gruppi threshold, che dovrà essere protetta economicamente, tramite depositi e il ritiro di fondi (slashing) dai partecipanti che non seguono il protocollo. Inoltre, la verifica BLS con un livello di sicurezza accettabile semplicemente non si adatta, ad esempio, a una transazione standard EOS o Ethereum — semplicemente non c'è tempo per la verifica. Il codice dei contratti è WebAssembly o EVM, eseguito da una macchina virtuale. Le funzioni crittografiche non sono implementate nativamente (per ora) e funzionano decine di volte più lentamente delle librerie crittografiche standard. Molti protocolli non soddisfano i requisiti semplicemente in base al numero di chiavi, ad esempio 1024 e 2048 bit per RSA, 4-8 volte di più rispetto alla firma standard di una transazione in Bitcoin ed Ethereum.

Gioca un ruolo anche la presenza di implementazioni in diversi linguaggi di programmazione, che sono poche, specialmente per i nuovi protocolli. L'opzione di 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. Il codice in JavaScript dovrà essere ricercato da tutti e, dato che JavaScript e crittografia non sono proprio amici, WebAssembly aiuterà, che ora ha sicuramente la pretesa di diventare il prossimo importante standard di internet.

Conclusione

Spero che nella precedente abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer. Sono riuscito a convincervi che la generazione di numeri casuali sulla blockchain è fondamentale per molti aspetti della vita delle reti decentralizzate, e con questo articolo ho dimostrato che si tratta di un compito estremamente ambizioso e complesso, ma buone soluzioni esistono già. In generale, il design finale del protocollo è possibile solo dopo aver condotto test massicci che considerino tutti gli aspetti, dall'impostazione all'emulazione dei guasti, quindi è improbabile che troviate ricette pronte nei whitepaper dei team e negli articoli, e noi sinceramente non ci sentiamo di scrivere "fate così, è sicuramente corretto" nei prossimi uno o due anni.

Fino ad ora, per il nostro PVRB nella blockchain in fase di sviluppo Haya, ci siamo fermati all'applicazione delle threshold BLS signatures, pianifichiamo di implementare il PVRB a livello di consenso, poiché la verifica nei contratti intelligenti con un livello di sicurezza accettabile non è ancora possibile. È possibile che utilizziamo due schemi: prima un costoso secret sharing per creare un random_seed a lungo termine, e lo utilizzeremo successivamente come base per la generazione ad alta frequenza di casualità tramite sigilli threshold BLS deterministici, potremmo limitarci a uno solo degli schemi. Dire in anticipo quale sarà il protocollo, purtroppo, è impossibile, ma l'unica cosa positiva è che, come nella scienza, nei compiti ingegneristici un risultato negativo è anch'esso un risultato, e ogni nuovo tentativo di risolvere il problema è un ulteriore passo verso la ricerca di tutti coloro che si occupano di questo tema. Per garantire i requisiti aziendali stiamo affrontando un compito pratico specifico: fornire alle applicazioni ludiche una fonte affidabile di entropia, quindi dobbiamo prestare attenzione anche alla stessa blockchain, in particolare alle questioni di finalità della catena e governance della rete.

E sebbene al momento non vediamo blockchain con un PVRB provato e resistente, utilizzato già da tempo sufficiente per affrontare le sfide di applicazioni reali, molteplici audit, carichi di lavoro e, naturalmente, attacchi reali, il numero delle possibili strade conferma che la soluzione esiste, e che uno di questi algoritmi alla fine risolverà il problema. Siamo felici di condividere i risultati e ringraziamo le altre squadre che stanno affrontando questo problema per gli articoli e il codice che permettono agli ingegneri di non inciampare due volte sugli stessi ostacoli.

Quindi, quando incontrate un programmatore che progetta un random decentralizzato, siate attenti e premurosi, offrendo supporto psicologico se necessario 🙂

Fonte: habr.com