Introduzione

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

Come per il concetto di cifratura assolutamente forte derivante dalla crittografia, i veri protocolli “Publicly Verifying Random Beacon” (di seguito PVRB) cercano solo di avvicinarsi il più possibile allo schema ideale, perché nelle reti reali non è applicabile nella sua forma pura: è necessario concordare rigorosamente su un bit, devono esserci molti giri e tutti i messaggi devono essere perfettamente veloci e sempre consegnati. Naturalmente questo non è il caso delle reti reali. Pertanto, quando si progettano PVRB per compiti specifici nelle moderne blockchain, oltre all'impossibilità di controllare la casualità e la forza crittografica risultanti, sorgono molti altri problemi puramente architettonici e tecnici.

Per PVRB, la blockchain stessa è essenzialmente un mezzo di comunicazione in cui messaggi = transazioni. Ciò consente di astrarre parzialmente dai problemi di rete, dalla mancata consegna dei messaggi, dai problemi con il middleware - tutti questi rischi sono assunti dalla rete decentralizzata e il suo valore principale per PVRB è l'impossibilità di revocare o corrompere una transazione già inviata - questo non non consentire ai partecipanti di rifiutarsi di partecipare al protocollo, a meno che non abbiano effettuato con successo un attacco al consenso. Questo livello di sicurezza è accettabile, quindi PVRB dovrebbe essere resistente alla collusione dei partecipanti esattamente nella stessa misura della catena blockchain principale. Inoltre, ciò suggerisce che il PVRB deve far parte del consenso se la rete è d’accordo sulla blockchain principale, anche se è d’accordo anche sull’unico risultato casuale equo. Oppure, PVRB è semplicemente un protocollo autonomo implementato da uno smart contract che funziona in modo asincrono rispetto alla blockchain e ai blocchi. Entrambi i metodi hanno i loro vantaggi e svantaggi e la scelta tra loro è estremamente non banale.

Due modi per implementare il PVRB

Descriviamo più in dettaglio due opzioni per l'implementazione del PVRB: la versione standalone, che funziona utilizzando un contratto intelligente indipendente dalla blockchain, e la versione integrata con consenso, integrata nel protocollo, secondo la quale la rete concorda sulla blockchain e transazioni da includere. In tutti i casi, intendo i popolari motori blockchain: Ethereum, EOS e tutti quelli simili a loro nel modo in cui ospitano ed elaborano contratti intelligenti.

Contratto autonomo

In questa versione, PVRB è un contratto intelligente che accetta transazioni di produttori casuali (di seguito denominati RP), le elabora, combina i risultati e, di conseguenza, arriva a un determinato valore che qualsiasi utente può ricevere da questo contratto. Questo valore non può essere memorizzato direttamente nel contratto, ma piuttosto essere rappresentato solo da dati dai quali è possibile ottenere in modo deterministico uno ed un solo valore del random risultante. In questo schema, gli RP sono utenti della blockchain e chiunque può essere autorizzato a partecipare al processo di generazione.

L'opzione con contratto autonomo è buona:

• portabilità (i contratti possono essere trascinati da blockchain a blockchain)
• facilità 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 scopi di PVRB)
• possibilità di lancio su blockchain già funzionanti

Presenta anche degli svantaggi:

• forti limitazioni sulle risorse di calcolo, sul volume delle transazioni e sullo spazio di archiviazione (in altre parole, cpu/mem/io)
• restrizioni sulle operazioni previste dal contratto (non tutte le istruzioni sono disponibili, è difficile collegare biblioteche esterne)
• incapacità di organizzare la messaggistica più velocemente di quanto le transazioni siano incluse nella blockchain

Questa opzione è adatta per implementare un PVRB che deve essere eseguito su una rete esistente, non contiene crittografia complessa e non richiede un gran numero di interazioni.

Consensus-integrato

In questa versione, PVRB è implementato nel codice del nodo blockchain, integrato o eseguito in parallelo con lo scambio di messaggi tra i nodi blockchain. I risultati del protocollo vengono scritti direttamente nei blocchi prodotti e i messaggi di protocollo vengono inviati sulla rete p2p tra i nodi. Poiché il protocollo produce numeri che devono essere scritti in blocchi, la rete deve raggiungere un consenso su di essi. Ciò significa che i messaggi PVRB, come le transazioni, devono essere convalidati dai nodi e inclusi in blocchi in modo che qualsiasi partecipante alla rete possa convalidare la conformità al protocollo PVRB. Questo ci porta automaticamente alla soluzione ovvia: se la rete concorda su un consenso su un blocco e sulle transazioni in esso contenute, allora PVRB dovrebbe essere parte del consenso e non un protocollo autonomo. Altrimenti è possibile che un blocco sia valido dal punto di vista del consenso, ma non venga seguito il protocollo PVRB e dal punto di vista del PVRB il blocco non possa essere accettato. Pertanto, se si sceglie l’opzione “integrata nel consenso”, il PVRB diventa una parte importante del consenso.

Quando si descrivono le implementazioni del PVRB a livello di consenso di rete, non si può in alcun modo evitare problemi di definitività. La finalità è un meccanismo utilizzato nei consensi deterministici che blocca un blocco (e la catena che lo conduce) che è definitivo e non verrà mai buttato via, anche se si verifica una biforcazione parallela. Ad esempio, in Bitcoin non esiste un meccanismo del genere: se pubblichi una catena di maggiore complessità, sostituirà quella meno complessa, indipendentemente dalla lunghezza delle catene. E in EOS, ad esempio, quelli 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 in attesa della firma di 2/3 dei produttori di blocchi (di seguito denominati BP). Quando compaiono fork più vecchi dell'ultima LIB, vengono semplicemente scartati. Questo meccanismo consente di garantire che la transazione sia inclusa nella blockchain e non verrà mai ripristinata, indipendentemente dalle risorse di cui dispone l’aggressore. Inoltre, i blocchi finali sono blocchi firmati da 2/3 BP in Hyperledger, Tendermint e altri consensi basati su pBFT. Inoltre, ha senso creare un protocollo per garantire la finalità in aggiunta al consenso, poiché può funzionare in modo asincrono con la produzione e la pubblicazione dei blocchi. Eccone uno buono articolo sulla finalità in Ethereum.

La finalità è estremamente importante per gli utenti, che senza di essa potrebbero ritrovarsi vittime di un attacco di “doppia spesa”, in cui BP “trattiene” i blocchi e li pubblica dopo che la rete ha “visto” una buona transazione. Se non esiste una finalità, il fork pubblicato sostituisce il blocco con una transazione “buona” con un altro, proveniente da un fork “cattivo”, in cui gli stessi fondi vengono trasferiti all’indirizzo dell’aggressore. Nel caso di PVRB, i requisiti di definitività sono ancora più rigorosi, poiché costruire fork per PVRB significa l'opportunità per un utente malintenzionato di preparare diverse opzioni casuali per pubblicare quella più redditizia, e limitare il tempo di un possibile attacco è un buona soluzione.

Pertanto, l'opzione migliore è combinare PVRB e finalità in un unico protocollo, quindi il blocco finalizzato = casuale finalizzato, e questo è esattamente ciò che dovevamo ottenere. Ora i giocatori riceveranno un risultato casuale garantito in N secondi e potranno essere sicuri che sarà impossibile ripristinarlo o riprodurlo di nuovo.

L’opzione integrata con consenso è buona:

• la possibilità di implementazione asincrona in relazione alla produzione di blocchi: i blocchi vengono prodotti come al solito, ma parallelamente a questo può funzionare il protocollo PVRB, che non produce casualità per ogni blocco
• la capacità di implementare anche una crittografia pesante, senza le restrizioni imposte ai contratti intelligenti
• la capacità di organizzare lo scambio di messaggi più velocemente di quanto le transazioni siano incluse nella blockchain, ad esempio, parte del protocollo può funzionare tra nodi senza distribuire messaggi sulla rete

Presenta anche degli svantaggi:

• Difficoltà nel test e nello sviluppo: dovrai emulare errori di rete, nodi mancanti, hard fork di rete
• Gli errori di implementazione richiedono un hardfork di rete

Entrambi i metodi di implementazione del PVRB hanno diritto alla vita, ma l'implementazione dei contratti intelligenti nelle moderne blockchain è ancora piuttosto limitata nelle risorse informatiche e qualsiasi transizione verso una crittografia seria è spesso semplicemente impossibile. E avremo bisogno di una crittografia seria, come verrà dimostrato di seguito. Sebbene questo problema sia chiaramente temporaneo, per risolvere molti problemi è necessaria una seria crittografia nei contratti, che sta gradualmente emergendo (ad esempio, i contratti di sistema per zkSNARK in Ethereum)

La blockchain, che fornisce un canale di messaggistica di protocollo trasparente e affidabile, non lo fa gratuitamente. Qualsiasi protocollo decentralizzato deve tenere conto della possibilità di un attacco Sybil; qualsiasi azione può essere compiuta dalle forze concertate di più account, pertanto, in fase di progettazione, è necessario tenere conto della capacità degli aggressori di creare un numero arbitrario di protocolli partecipanti che agiscono in collusione.

PVRB e variabili di blocco.

Non ho mentito quando ho detto che nessuno ha ancora implementato un buon PVRB, testato da molte applicazioni di gioco d’azzardo, nelle blockchain. Da dove provengono allora così tante applicazioni di gioco d’azzardo su Ethereum ed EOS? Questo mi sorprende tanto quanto sorprende te, dove hanno preso così tanti casuali “persistenti” in un ambiente completamente deterministico?

Il modo preferito per ottenere casualità nella blockchain è prendere qualche tipo di informazione "imprevedibile" dal blocco e crearne una casuale basata su di essa, semplicemente eseguendo l'hashing di uno o più valori. Buon articolo sui problemi di tali schemi qui. Puoi prendere uno qualsiasi dei valori "imprevedibili" nel blocco, ad esempio l'hash del blocco, il numero di transazioni, la complessità della rete e altri valori sconosciuti in anticipo. Quindi eliminali, uno o più, e, in teoria, dovresti ottenere un vero random. Puoi anche aggiungere al documento bianco che il tuo schema è "post-quantum secure" (poiché esistono funzioni hash a prova quantistica :)).

Ma purtroppo anche gli hash sicuri post-quantistici non sono sufficienti. Il segreto sta nei requisiti per PVRB, lascia che te li ricordi dall'articolo precedente:

1. Il risultato deve avere una distribuzione uniforme e dimostrabile, cioè essere basato su una crittografia forte e dimostrabile.
2. Non è possibile controllare nessuno dei bit del risultato. Di conseguenza, il risultato non può essere previsto in anticipo.
3. Non è possibile sabotare il protocollo di generazione non partecipando al protocollo o sovraccaricando la rete con messaggi di attacco
4. Tutto quanto sopra deve essere resistente alla collusione di un numero consentito di partecipanti al protocollo disonesti (ad esempio, 1/3 dei partecipanti).

In questo caso, è soddisfatto solo il requisito 1 e non il requisito 2. Eseguendo l'hashing di valori imprevedibili dal blocco, otterremo una distribuzione uniforme e una buona casualità. Ma la BP almeno ha la possibilità di “pubblicare il blocco oppure no”. Pertanto, la BP può almeno scegliere tra DUE opzioni casuali: “la propria” e quella che risulterà se qualcun altro effettuasse il blocco. BP può “curiosare” in anticipo cosa accadrà se pubblica un blocco, e semplicemente decide se farlo o meno. Pertanto, quando si gioca, ad esempio, alla roulette “pari-dispari” o “rosso/nero”, può pubblicare un blocco solo se vede una vincita. Ciò rende impraticabile anche la strategia di utilizzare, ad esempio, un block hash “dal futuro”. In questo caso, dicono, “verrà utilizzato il random, che si ottiene eseguendo l’hashing dei dati attuali e dell’hash di un blocco futuro con un’altezza, ad esempio, N + 42, dove N è l’altezza attuale del blocco. Ciò rafforza un po’ lo schema, ma consente comunque alla BP, anche se in futuro, di scegliere se mantenere il blocco o pubblicare.

Il software BP in questo caso diventa più complicato, ma non di molto. Semplicemente, quando si convalida e si include una transazione in un blocco, si verifica rapidamente se ci sarà una vincita e, eventualmente, si seleziona un parametro di transazione per ottenere un'alta probabilità di vincita. Allo stesso tempo, è quasi impossibile catturare un BP intelligente per tali manipolazioni; ogni volta puoi utilizzare nuovi indirizzi e vincere a poco a poco senza destare sospetti.

Pertanto i metodi che utilizzano le informazioni del blocco non sono adatti come implementazione universale di PVRB. In una versione limitata, con restrizioni sull'entità delle scommesse, restrizioni sul numero di giocatori e/o registrazione KYC (per impedire a un giocatore di utilizzare più indirizzi), questi schemi possono funzionare per piccoli giochi, ma niente di più.

PVRB e commit-reveal.

Ok, grazie all'hashing e almeno alla relativa imprevedibilità dell'hash del blocco e di altre variabili. Se risolvi il problema dei minatori in prima linea, dovresti ottenere qualcosa di più adatto. Aggiungiamo gli utenti a questo schema: lasciamo che influenzino anche la casualità: qualsiasi dipendente 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, ad esempio, come un hash della loro somma, non è adatto. In questo caso, l'ultimo giocatore può, scegliendo il proprio casuale, controllare quale sarà il risultato. Questo è il motivo per cui viene utilizzato il modello commit-reveal molto diffuso. I partecipanti prima inviano gli hash dai loro random (commit), quindi aprono i random stessi (reveal). La fase di “reveal” inizia solo dopo che sono stati raccolti i commit necessari, quindi i partecipanti possono inviare esattamente l’hash casuale da cui hanno inviato in precedenza. Ora mettiamo insieme tutto questo con i parametri di un blocco, e meglio di uno preso dal futuro (la casualità può essere trovata solo in uno dei blocchi futuri), e voilà: la casualità è pronta! Ora qualsiasi giocatore influenza la casualità risultante e può "sconfiggere" il BP dannoso sovrascrivendolo con la sua casualità, sconosciuta in anticipo... Puoi anche aggiungere protezione contro il sabotaggio del protocollo non aprendolo nella fase di rivelazione - semplicemente richiedendo che un determinato importo venga allegato alla transazione al momento dell'impegno, ovvero un deposito cauzionale, che verrà restituito solo durante la procedura di rivelazione. In questo caso, impegnarsi e non rivelarlo non sarà redditizio.

È stato un buon tentativo e tali schemi esistono anche nei DApp di gioco, ma purtroppo anche questo non è sufficiente. Ora non solo il minatore, ma anche qualsiasi partecipante al protocollo può influenzare il risultato. È ancora possibile controllare il valore stesso, con minore variabilità e a pagamento, ma, come nel caso del miner, se i risultati dell'estrazione valgono più della quota di partecipazione al protocollo PVRB, allora il random -il produttore(RP) può decidere se rivelare e può comunque scegliere tra almeno due opzioni casuali.
Ma è diventato possibile punire chi si impegna e non lo rivela, e questo schema tornerà utile. La sua semplicità è un grande vantaggio: protocolli più seri richiedono calcoli molto più potenti.

PVRB e firme deterministiche.

Esiste un altro modo per forzare l'RP a fornire un numero pseudo-casuale che non può influenzare se gli viene fornita una "preimmagine": questa è una firma deterministica. Tale firma è, ad esempio, RSA e non ECS. Se RP ha una coppia di chiavi: RSA ed ECC, e firma un certo valore con la sua chiave privata, allora nel caso di RSA otterrà UNA ED UNA SOLA firma, e nel caso di ECS potrà generare un numero qualsiasi di diverse firme valide. Questo perché quando si crea una firma ECS viene utilizzato un numero casuale, scelto dal firmatario, e può essere scelto in qualsiasi modo, dando la possibilità al firmatario di scegliere una tra più firme. Nel caso di RSA: “un valore di input” + “una coppia di chiavi” = “una firma”. È impossibile prevedere quale firma riceverà un altro RP, quindi è possibile organizzare un PVRB con firme deterministiche combinando le firme RSA di diversi partecipanti che hanno firmato lo stesso valore. Ad esempio, il precedente casuale. Questo schema consente di risparmiare molte risorse, perché le firme sono sia conferma del comportamento corretto secondo il protocollo sia fonte di casualità.

Tuttavia, anche con firme deterministiche, lo schema è ancora vulnerabile al problema dell’“ultimo attore”. L'ultimo partecipante potrà comunque decidere se pubblicare o meno la firma, controllandone così l'esito. È possibile modificare lo schema, aggiungervi hash di blocco, fare giri in modo che il risultato non possa essere previsto in anticipo, ma tutte queste tecniche, anche tenendo conto di molte modifiche, lasciano comunque irrisolto il problema dell'influenza di un partecipante sul collettivo si traducono in un ambiente non affidabile e possono funzionare solo con vincoli economici e di tempo. Inoltre, la dimensione delle chiavi RSA (1024 e 2048 bit) è piuttosto elevata e la dimensione delle transazioni blockchain è un parametro estremamente importante. A quanto pare non esiste un modo semplice per risolvere il problema, andiamo avanti.

PVRB e schemi di condivisione segreta

Nella crittografia, esistono schemi che possono consentire alla rete di accordarsi su uno ed un solo valore PVRB, mentre tali schemi sono resistenti a qualsiasi azione dannosa di alcuni partecipanti. Un protocollo utile con cui vale la pena familiarizzare è lo schema di condivisione segreta di Shamir. Serve a dividere un segreto (ad esempio una chiave segreta) in più parti e distribuire queste parti a N partecipanti. Il segreto è distribuito in modo tale che per recuperarlo siano sufficienti M parti su N, e queste possono essere M parti qualsiasi. Se sulle dita, avendo un grafico di una funzione sconosciuta, i partecipanti si scambiano punti sul grafico e, dopo aver ricevuto M punti, l'intera funzione può essere ripristinata.
Viene fornita una buona spiegazione wiki ma giocarci praticamente per riprodurre il protocollo nella tua testa è utile dimostrazione pagina.

Se lo schema FSSS (Fiat-Shamir Secret Sharing) fosse applicabile nella sua forma pura, sarebbe un PVRB indistruttibile. Nella sua forma più semplice, il protocollo potrebbe assomigliare a questo:

• Ogni partecipante genera il proprio random e ne distribuisce le quote agli altri partecipanti
• Ogni partecipante svela la sua parte dei segreti degli altri partecipanti
• Se un partecipante ha più di M azioni, è possibile calcolare il numero di questo partecipante e sarà unico, indipendentemente dall'insieme di partecipanti rivelati
• La combinazione di casuali rivelati è il PVRB desiderato

Qui il singolo partecipante non influenza più i risultati del protocollo, tranne nei casi in cui il raggiungimento della soglia di divulgazione della casualità dipende solo da lui. Pertanto, questo protocollo, se esiste una percentuale richiesta di RP che lavorano sul protocollo e sono disponibili, funziona, implementando i requisiti per la forza crittografica e resistendo al problema dell’“ultimo attore”.

Questa potrebbe essere un'opzione ideale, questo schema PVRB basato sulla condivisione segreta di Fiat-Shamir è descritto ad esempio in questo articolo. Ma, come accennato in precedenza, se si tenta di applicarlo direttamente nella blockchain, compaiono limitazioni tecniche. Ecco un esempio di implementazione di prova del protocollo nello smart contract EOS e la sua parte più importante: il controllo del partecipante alla condivisione pubblicata: codice. Puoi vedere dal codice che la convalida della prova richiede diverse moltiplicazioni scalari e i numeri utilizzati sono molto grandi. Dovrebbe essere chiaro che nelle blockchain la verifica avviene nel momento in cui il produttore del blocco elabora la transazione e, in generale, qualsiasi partecipante deve verificare facilmente la correttezza del protocollo, quindi i requisiti per la velocità della funzione di verifica sono molto seri . In questa opzione, l'opzione si è rivelata inefficace, poiché la verifica non rientrava nel limite della transazione (0.5 secondi).

L’efficienza della verifica è uno dei requisiti più importanti per l’utilizzo, in generale, di qualsiasi schema crittografico avanzato nella blockchain. Creare prove, preparare messaggi: queste procedure possono essere portate fuori catena ed eseguite su computer ad alte prestazioni, ma la verifica non può essere aggirata: questo è un altro requisito importante per PVRB.

PVRB e firme di soglia

Dopo aver conosciuto lo schema di condivisione segreta, abbiamo scoperto un'intera classe di protocolli accomunati dalla parola chiave "soglia". Quando la divulgazione di alcune informazioni richiede la partecipazione di M partecipanti onesti su N, e l’insieme dei partecipanti onesti può essere un sottoinsieme arbitrario di N, si parla di schemi “a soglia”. Sono loro che ci permettono di affrontare il problema dell'“ultimo attore”, ora se l'aggressore non rivela la sua parte di segreto, un altro partecipante onesto lo farà per lui. Questi schemi consentono l’accordo su uno ed un solo significato, anche se il protocollo viene sabotato da alcuni dei partecipanti.

La combinazione di firme deterministiche e schemi di soglia ha permesso di sviluppare uno schema molto conveniente e promettente per l'implementazione del PVRB: si tratta di firme di soglia deterministiche. Qui articolo sui vari usi delle firme di soglia, ed eccone un altro valido longread da Dash.

L'ultimo articolo descrive le firme BLS (BLS sta per Boneh-Lynn-Shacham, qui articolo), che hanno una qualità molto importante ed estremamente conveniente per i programmatori: le chiavi pubbliche, segrete, pubbliche e le firme BLS possono essere combinate tra loro utilizzando semplici operazioni matematiche, mentre le loro combinazioni rimangono chiavi e firme valide, consentendo di aggregare facilmente molti firme in una e molte chiavi pubbliche in una. Sono anche deterministici e producono lo stesso risultato per gli stessi dati di input. Grazie a questa qualità, le combinazioni di firme BLS sono esse stesse chiavi valide, il che consente l'implementazione di un'opzione in cui M di N partecipanti producono una ed una sola firma deterministica, verificabile pubblicamente e imprevedibile finché non viene aperta dall'Mth partecipante.

In uno schema con firme BLS a soglia, ciascun partecipante firma qualcosa utilizzando BLS (ad esempio, il casuale precedente) e la firma a soglia comune è il casuale desiderato. Le proprietà crittografiche delle firme BLS soddisfano i requisiti di qualità casuale, la parte soglia protegge dal "last-actor" e la combinabilità unica delle chiavi consente di implementare molti altri algoritmi interessanti che consentono, ad esempio, un'aggregazione efficiente dei messaggi del protocollo .

Quindi, se stai costruendo PVRB sulla tua blockchain, molto probabilmente ti ritroverai con lo schema delle firme delle soglie BLS, diversi progetti lo stanno già utilizzando. Ad esempio, DFinity (qui benchmark che implementa il circuito, e qui esempio di implementazione di condivisione segreta verificabile) o Keep.network (ecco il loro beacon casuale carta gialla, Ma esempio contratto intelligente al servizio del protocollo).

Attuazione del PVRB

Sfortunatamente, non vediamo ancora un protocollo già pronto implementato nelle blockchain PVRB che abbia dimostrato la sua sicurezza e stabilità. Anche se i protocolli stessi sono pronti, applicarli tecnicamente alle soluzioni esistenti non è facile. Per i sistemi centralizzati, il PVRB non ha senso e quelli decentralizzati sono strettamente limitati in tutte le risorse di calcolo: CPU, memoria, storage, I/O. Progettare un PVRB è una combinazione di diversi protocolli al fine di creare qualcosa che soddisfi tutti i requisiti per almeno una blockchain praticabile. Un protocollo calcola in modo più efficiente, ma richiede più messaggi tra RP, mentre l'altro richiede pochissimi messaggi, ma creare una prova può essere un'attività che richiede decine di minuti o addirittura ore.

Elencherò i fattori che dovrai considerare nella scelta di un PVRB di qualità:

• Forza crittografica. Il tuo PVRB deve essere rigorosamente imparziale, senza capacità di controllare un singolo bit. In alcuni schemi questo non è il caso, quindi chiama un crittografo
• Il problema dell’“ultimo attore”.. Il tuo PVRB deve essere resistente agli attacchi in cui un attaccante che controlla uno o più RP può scegliere uno dei due risultati.
• Problema del sabotaggio del protocollo. Il tuo PVRB deve essere resistente agli attacchi in cui un attaccante che controlla uno o più RP decide se essere casuali o meno e può essere garantito o con una determinata probabilità di influenzarlo
• Problema relativo al numero di messaggi. I tuoi RP dovrebbero inviare un minimo di messaggi alla blockchain ed evitare il più possibile azioni sincrone come situazioni come "Ho inviato alcune informazioni, sto aspettando una risposta da un partecipante specifico". Nelle reti p2p, soprattutto in quelle geograficamente disperse, non dovresti contare su una risposta rapida
• Il problema della complessità computazionale. La verifica di qualsiasi fase del PVRB on-chain dovrebbe essere estremamente semplice, poiché viene eseguita da tutti i client completi della rete. Se l’implementazione viene eseguita utilizzando un contratto intelligente, i requisiti di velocità sono molto severi
• Il problema dell’accessibilità e della vivibilità. Il tuo PVRB dovrebbe sforzarsi di essere resiliente alle situazioni in cui parte della rete diventa non disponibile per un periodo di tempo e parte dell'RP semplicemente smette di funzionare
• Il problema della configurazione affidabile e della distribuzione iniziale delle chiavi. Se il tuo PVRB utilizza la configurazione primaria del protocollo, allora questa è una storia grande e seria a parte. Qui esempio. Se i partecipanti devono comunicarsi reciprocamente le chiavi prima di iniziare il protocollo, anche questo diventa un problema se la composizione dei partecipanti cambia
• Problemi di sviluppo. Disponibilità di librerie nelle lingue richieste, loro sicurezza e prestazioni, pubblicità, test complessi, ecc.

Ad esempio, le firme BLS con soglia presentano un problema significativo: prima di iniziare a lavorare, i partecipanti devono distribuirsi le chiavi tra loro, organizzando un gruppo all'interno del quale lavorerà la soglia. Ciò significa che almeno un giro di scambio in una rete decentralizzata dovrà attendere, e dato che il rand generato, ad esempio, è necessario nei giochi, quasi in tempo reale, ciò significa che in questa fase è possibile un sabotaggio del protocollo , e i vantaggi del sistema a soglia vengono perduti. Questo problema è già più semplice dei precedenti, ma richiede comunque lo sviluppo di una procedura separata per la formazione dei gruppi soglia, che dovranno essere tutelati economicamente, attraverso depositi e prelievi di fondi (slashing) dai partecipanti che non seguono le protocollo. Inoltre, la verifica BLS con un livello di sicurezza accettabile semplicemente non si adatta, ad esempio, a una transazione EOS o Ethereum standard: semplicemente non c'è abbastanza tempo per la verifica. Il codice del contratto è WebAssembly o EVM, eseguito da una macchina virtuale. Le funzioni crittografiche non sono (ancora) implementate in modo nativo e funzionano decine di volte più lentamente delle librerie crittografiche convenzionali. Molti protocolli non soddisfano i requisiti basati semplicemente sul volume della chiave, ad esempio 1024 e 2048 bit per RSA, 4-8 volte più grandi della firma di transazione standard in Bitcoin ed Ethereum.

Anche la presenza di implementazioni in diversi linguaggi di programmazione gioca un ruolo, di cui ce ne sono poche, soprattutto per i nuovi protocolli. L'opzione con integrazione nel consenso richiede la scrittura di un protocollo nel linguaggio della piattaforma, quindi dovrai cercare il codice in Go per geth, in Rust per Parity, in C++ per EOS. Tutti dovranno cercare il codice JavaScript e poiché JavaScript e la crittografia non sono particolarmente amici, WebAssembly aiuterà, che ora afferma definitivamente di essere il prossimo importante standard Internet.

conclusione

Spero nel precedente Articolo Sono riuscito a convincerti che generare numeri casuali sulla blockchain è fondamentale per molti aspetti della vita delle reti decentralizzate, e con questo articolo ho dimostrato che questo compito è estremamente ambizioso e difficile, ma esistono già buone soluzioni. In generale, la progettazione finale del protocollo è possibile solo dopo aver condotto test massicci che tengono conto di tutti gli aspetti, dalla configurazione all'emulazione dei guasti, quindi difficilmente troverete ricette già pronte nei white paper e negli articoli del team, e di certo non lo troveremo decidere nel prossimo anno o due di scrivere “fallo in questo modo, esattamente nel modo giusto”.

Ciao, per il nostro PVRB nella blockchain in fase di sviluppo Haya, abbiamo deciso di utilizzare le firme BLS con soglia, prevediamo 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 contemporaneamente: in primo luogo, una costosa condivisione segreta per creare random_seed a lungo termine, quindi lo usiamo come base per la generazione casuale ad alta frequenza utilizzando firme BLS con soglia deterministica, forse ci limiteremo solo a uno degli schemi. Purtroppo è impossibile dire in anticipo quale sarà il protocollo; l’unica cosa positiva è che, come nella scienza, nei problemi di ingegneria, anche un risultato negativo è un risultato, e ogni nuovo tentativo di risolvere il problema è un ulteriore passo per la ricerca di tutti coloro che sono coinvolti nel problema. Per soddisfare i requisiti aziendali, risolviamo un problema pratico specifico: fornire alle applicazioni di gioco una fonte affidabile di entropia, quindi dobbiamo prestare attenzione anche alla blockchain stessa, in particolare alle questioni relative alla finalità della catena e alla governance della rete.

E anche se non vediamo ancora un PVRB resistente e comprovato nelle blockchain, che sarebbe stato utilizzato per un tempo sufficiente per essere testato da applicazioni reali, audit multipli, carichi e, naturalmente, attacchi reali, ma il numero di percorsi possibili lo conferma esiste una soluzione e quale di questi algoritmi alla fine risolverà il problema. Saremo felici di condividere i risultati e ringraziare altri team che stanno lavorando su questo problema per articoli e codici che consentono agli ingegneri di non calpestare due volte lo stesso rastrello.

Quindi, quando incontri un programmatore che progetta casualità decentralizzata, sii attento e premuroso e fornisci aiuto psicologico se necessario :)

Fonte: habr.com