Quindi, il tuo team ha terminato la versione alpha della tua blockchain ed è ora di lanciare testnet e poi mainnet. Hai una vera blockchain, con partecipanti indipendenti, un buon modello economico, sicurezza, hai progettato la governance e ora è il momento di provare tutto questo in azione. In un mondo cripto-anarchico ideale, metti il blocco genesi sulla rete, il codice finale del nodo e gli stessi validatori lanciano tutto, sollevano tutti i servizi ausiliari e tutto accade da solo. Ma questo è in un mondo immaginario, ma nel mondo reale il team deve preparare una grande quantità di software ausiliario e varie manipolazioni per aiutare i validatori a lanciare una rete stabile. Questo è ciò di cui tratta questo articolo.
Il lancio di reti basate su consensi di tipo “proof-of-stake”, dove i validatori sono determinati dai voti dei possessori di token di sistema, è un evento piuttosto specifico, perché anche il lancio di sistemi tradizionali gestiti centralmente con decine e centinaia di server non è un compito facile. compito in sé, e la blockchain deve essere avviata con impegno da parte di partecipanti leali ma indipendenti. E, se in un'azienda, all'avvio, gli amministratori hanno pieno accesso a tutte le macchine, ai registri, al monitoraggio generale, i validatori non consentiranno a nessuno di accedere ai propri server e, molto probabilmente, preferiranno costruire la propria infrastruttura in modo indipendente, perché controlla l'accesso alle risorse principali del validatore: puntate elettorali. È questo comportamento che rende possibile costruire reti distribuite sicure - l'indipendenza dei fornitori cloud utilizzati, server virtuali e "baremetal", diversi sistemi operativi, tutto ciò consente di rendere estremamente inefficaci gli attacchi a tale rete - troppo diversi viene utilizzato il software. Ad esempio, Ethereum utilizza due implementazioni del nodo principale, in Go e in Rust, e un attacco efficace per un’implementazione non funziona per l’altra.
Pertanto, tutti i processi per il lancio e il funzionamento delle blockchain devono essere organizzati in modo tale che qualsiasi validatore, o anche un piccolo gruppo di validatori, possa in qualsiasi momento lanciare i propri computer dalla finestra e andarsene, mentre nulla dovrebbe rompersi e i rimanenti validatori dovrebbero continuare a supportare efficacemente la rete operativa e connettere nuovi validatori. Quando si lancia una rete, quando un validatore è in Europa, il secondo in Sud America e il terzo in Asia, è abbastanza difficile ottenere il lavoro coordinato di diverse dozzine di gruppi indipendenti e di conseguenza interessarli.
Validatori
Immaginiamo il lancio di un'ipotetica blockchain moderna (la maggior parte di ciò che viene descritto è adatto per blockchain basati su qualsiasi moderna famiglia di blockchain: Ethereum, EOS, Polkadot, Cosmos e altri, che forniscono consenso proof-of-stake. I personaggi principali di tali blockchain sono team di validatori, impegnati a installare i propri server indipendenti che validano e producono nuovi blocchi, e ricevono ricompense fornite dalla rete per coloro che partecipano al consenso. Per lanciare nuove reti, sono necessarie diverse dozzine di validatori (tanti possono ora raggiungono più o meno efficacemente il consenso in pochi secondi), quindi il progetto annuncia la registrazione, in cui i validatori condividono informazioni pubbliche su se stessi con gli utenti, convincendoli che forniranno un servizio di alta qualità alla rete lanciata.
La convalida è un'attività che consente di valutare in modo estremamente accurato il potenziale reddito del validatore, trasferire rapidamente potere tra progetti e, se la rete che ha scelto ha successo, il validatore può, in quanto partecipante a pieno titolo alla DAO e persona responsabile, sviluppare il progetto o semplicemente fornire un eccellente servizio tecnico in cambio di denaro completamente trasparente e onestamente guadagnato. Nel calcolare la ricompensa per i validatori, i progetti cercano di tenere conto dei costi dei validatori e di ricompensare i blocchi in modo tale che questa attività sia redditizia, ma allo stesso tempo non consentono ai validatori di far crollare l'economia inondandoli di denaro e privandone gli altri utenti della rete.
L'attività dei validatori richiede la garanzia di un'elevata tolleranza agli errori dei servizi, il che significa un elevato livello di formazione per devop e sviluppatori e costose risorse informatiche. Anche senza la necessità di estrarre gli hash nelle reti proof-of-work, un nodo blockchain è un servizio di grandi dimensioni che occupa molta memoria, consuma molti calcoli, convalida, scrive su disco e invia grandi quantità di dati alla rete . Per archiviare i registri delle transazioni e le catene di blocchi per una blockchain con diverse migliaia di piccole transazioni in un blocco, ora è necessario uno spazio di archiviazione di 50 Gb o più e per i blocchi deve essere un SSD. Il database statale delle blockchain con supporto per i contratti intelligenti può già superare i 64 GB di RAM. I server con le caratteristiche richieste sono piuttosto costosi; un nodo Ethereum o EOS può costare dai 100 ai 200 $/mese. A questo si aggiunge l'aumento degli stipendi per il lavoro 10 ore su 000 di sviluppatori e devop, che durante il periodo di lancio risolvono i problemi anche di notte, poiché alcuni validatori possono facilmente trovarsi in un altro emisfero. Tuttavia, al momento giusto, possedere un nodo di validazione può portare guadagni considerevoli (nel caso di EOS, fino a XNUMX dollari al giorno).
La validazione è solo uno dei nuovi potenziali ruoli IT per imprenditori e aziende; man mano che i programmatori escogitano algoritmi sempre più sofisticati che premiano l'onestà e puniscono frodi e furti, compaiono servizi che svolgono le funzioni di pubblicazione di dati importanti (oracoli), di supervisione (riduzione dei depositi e punizione degli imbroglioni pubblicando prove dell’inganno), servizi di risoluzione delle controversie, assicurazioni e opzioni, persino la raccolta dei rifiuti è un mercato potenzialmente ampio nei sistemi di contratti intelligenti in cui è necessario pagare per l’archiviazione dei dati.
Problemi di lancio di una blockchain
L’apertura della blockchain, che ha permesso ai computer di qualsiasi paese di partecipare liberamente alla rete e la facilità di connettere qualsiasi script kiddie alla rete secondo le istruzioni su GitHub, non è sempre un vantaggio. La ricerca di un nuovo token spesso costringe i validatori a “estrarre una nuova moneta all’inizio”, nella speranza che il tasso aumenti e abbiano l’opportunità di smaltire rapidamente i propri guadagni. Inoltre, questo significa che il tuo validatore può essere chiunque, anche una persona anonima, puoi votare per lui allo stesso modo degli altri validatori (tuttavia, sarà difficile per una persona anonima raccogliere i voti degli stakeholder per se stesso, quindi noi' lascerò ai politici le storie spaventose sulle criptovalute anonime). Tuttavia
Il team di progetto ha il compito di inserire in qualche modo nella sua rete coloro che in futuro saranno in grado di garantire il funzionamento stabile dei nodi, comprendere la sicurezza, sapere come risolvere rapidamente i problemi, collaborare con altri validatori e agire insieme - la qualità di ciò Tutto dipende interamente da queste qualità: un segno in cui i partecipanti alla rete investiranno il loro tempo e le loro risorse. I fondatori adeguati, nel valutare i rischi, comprendono bene che quando si avvia software di queste dimensioni, si dovranno sicuramente riscontrare errori nel codice e nella configurazione dei nodi e che la stabilità della rete dipende da quanto bene sviluppatori e validatori risolveranno congiuntamente tali problemi.
Il team è pronto a votare sulla mainnet per eventuali validatori, solo per sapere quali, quali sono buoni? Il portafoglio più grande? Ormai non ce l'ha quasi più nessuno. Basandosi sui profili Linkedin della squadra? Devop esperti o specialisti della sicurezza non ti forniranno alcun profilo Linkedin. Secondo dichiarazioni in chat, post e aiutando gli altri durante la fase di preparazione? Buono, ma soggettivo e impreciso.
In tali condizioni, rimane una cosa - qualcosa che risolve bene i problemi di tutti - un gioco in cui sarà possibile selezionare i migliori validatori, ma la cosa principale è testare la forza della blockchain e condurre un test di combattimento su vasta scala del blockchain in condizioni di utilizzo attivo, cambiamenti nel consenso, comparsa e correzione degli errori. Questa procedura è stata presentata inizialmente come un gioco dai ragazzi del progetto Cosmos, e questa idea è senza dubbio un ottimo modo per preparare la rete al lancio di una mainnet affidabile e tollerante ai guasti
Gioco dei validatori
Descriverò il gioco dei validatori così come lo abbiamo progettato per la blockchain DAO.Casino (DAOBet) basata sul fork EOS, che si chiama Haya e ha un meccanismo di governance simile: i validatori vengono scelti votando da qualsiasi account, in cui parte di il saldo utilizzato per votare per il validatore è congelato. Qualsiasi conto che abbia il token BET principale sul suo saldo può votare per il validatore selezionato con qualsiasi parte del suo saldo. I voti vengono riassunti e i migliori validatori vengono costruiti in base ai risultati. Nelle diverse blockchain questo processo è organizzato in modo diverso, e di solito è in questa parte che la nuova blockchain differisce da quella madre, e devo dire che nel nostro caso EOS giustifica pienamente la parola "OS" nel suo nome, noi usiamo davvero EOS come sistema operativo di base per l'implementazione di una versione modificata della blockchain per le attività DAOBet.
Descriverò i singoli problemi e come possono essere risolti all'interno del gioco. Immaginiamo una rete in cui il tuo server può essere attaccato apertamente, dove per mantenere la posizione di validatore devi interagire continuamente con la rete, promuovendo il tuo validatore e assicurandoti che produca blocchi e questi vengano consegnati ad altri validatori su tempo, altrimenti il validatore verrà espulso dalla lista.
Come scegliere i migliori vincitori?
Il principale requisito tecnico del gioco è che i suoi risultati siano pubblicamente verificabili. Ciò significa che i risultati del gioco: vincitori TOP, devono essere formati rigorosamente sulla base di dati che possono essere verificati da qualsiasi partecipante. In un sistema centralizzato, potremmo misurare il “tempo di attività” di ciascun validatore e premiare chi è stato più online o ha attraversato il massimo traffico di rete. Puoi raccogliere dati sul carico del processore e della memoria e premiare chi ha lavorato bene. Ma qualsiasi raccolta di parametri di questo tipo implica l’esistenza di un centro di raccolta e i nodi sono tutti indipendenti e possono comportarsi come vogliono e inviare qualsiasi dato.
Pertanto, la soluzione naturale è che i vincitori vengano determinati sulla base dei dati della blockchain, poiché possono essere utilizzati per vedere quale validatore ha prodotto quale blocco e quali transazioni sono state incluse in esso. Abbiamo chiamato questo numero Validator Points (VP) e guadagnarli è l'obiettivo principale dei validatori nel gioco. Nel nostro caso, la metrica più semplice, facilmente verificabile pubblicamente ed efficace dell’“utilità” di un validatore è VP = numero di blocchi prodotti dal validatore in un dato periodo di tempo.
Questa semplice scelta è dovuta al fatto che la governance in EOS prevede già molti problemi emergenti, poiché EOS è l'erede di tre generazioni di blockchain realmente funzionanti con una vasta esperienza nella gestione di reti complesse e quasi tutti i problemi di validazione con rete, processore, disk porta a un solo problema: firma meno blocchi, riceve meno pagamenti per il lavoro, il che ci porta ancora una volta semplicemente al numero di blocchi firmati: per EOS questa è un'opzione eccellente e semplice.
Per altre blockchain, il modo in cui vengono calcolati i Validator Points può differire, ad esempio, per i consensi basati su pBFT (Tendermint/Cosmos, Aura consensus di Parity Substrate), dove ogni blocco deve essere firmato da più validatori, ha senso contare i singoli validatori firme piuttosto che blocchi. Potrebbe avere senso prendere in considerazione i cicli di consenso incompleti, che sprecano le risorse di altri validatori, in generale ciò dipende molto dal tipo di consenso.
Come simulare condizioni operative reali
Il compito dei fondatori è testare i validatori in condizioni vicine alla realtà, senza avere alcun controllo centralizzato. Questo problema può essere risolto utilizzando un contratto faucet, che distribuisce quantità uguali del token principale ai validatori e a tutti gli altri. Per ricevere token sul tuo saldo, devi creare una transazione e assicurarti che la rete la includa nel blocco. Pertanto, per vincere, un validatore deve ricostituire costantemente il suo saldo con nuovi gettoni e votare per se stesso, promuovendosi ai vertici. Questa attività crea un carico costante sulla rete e i parametri possono essere selezionati in modo che il flusso di richieste sia sufficientemente intenso per un test completo della rete. Pertanto, pianifica in anticipo il contratto del faucet come strumento importante per lanciare la rete e inizia a selezionarne i parametri in anticipo.
Richiedere token da un faucet e convalidare voti non emula ancora del tutto il funzionamento di una testata, soprattutto in modalità estremamente caricate. Pertanto, il team blockchain dovrà comunque scrivere ulteriori benchmark in un modo o nell’altro per caricare la rete. Un ruolo speciale in questo è svolto dai contratti intelligenti appositamente creati che consentono di testare un sottosistema separato. Per testare l'archiviazione, il contratto memorizza dati casuali nella blockchain e per testare le risorse di rete, il contratto di test richiede una grande quantità di dati di input, gonfiando così il volume delle transazioni, avviando un flusso di tali transazioni in momenti arbitrari nel tempo, il team testa contemporaneamente la stabilità del codice e la forza dei validatori.
Una questione separata è l'aggiornamento del codice dei nodi e la conduzione degli hard fork. È necessario che in caso di bug, vulnerabilità o collusione di validatori dannosi, i validatori abbiano un piano d’azione che è già stato elaborato nel gioco dei validatori. Qui puoi elaborare schemi per accumulare VP per applicare rapidamente un hard fork, ad esempio multando tutti i validatori che non hanno ancora implementato una nuova versione del codice del nodo, ma questo è difficile da implementare e complica il calcolo. Puoi simulare la situazione di un utilizzo di emergenza di un hard fork “rompendo” artificialmente la blockchain su un dato blocco. La produzione dei blocchi si ferma e alla fine i vincitori saranno coloro che entreranno per primi e inizieranno a firmare i blocchi, quindi i VP basati sul numero di blocchi firmati sono una buona soluzione in questo caso.
Come informare i partecipanti sullo stato della rete e correggere gli errori
Nonostante la sfiducia tra i validatori, la ricezione tempestiva di informazioni aggiornate sullo stato della rete è vantaggiosa per tutti per poter prendere decisioni più rapidamente, quindi il team di progetto sta creando un servizio per la raccolta e la visualizzazione di molti parametri dai server dei validatori, che ti consente di vedere la situazione simultaneamente per l'intera rete, permettendoti di determinare rapidamente cosa sta succedendo. Inoltre, è vantaggioso sia per i validatori che per il progetto che il team di progetto corregga rapidamente gli errori rilevati, quindi oltre a raccogliere parametri, ha senso iniziare immediatamente a raccogliere log e dati di errore dalle macchine dei validatori su una macchina accessibile alla blockchain sviluppatori. In questo caso non è vantaggioso per nessuno distorcere le informazioni, quindi questi servizi sono sviluppati dal team di progetto e ci si può fidare. Ha senso raccogliere le metriche di sistema dai validatori e, ovviamente, le metriche più importanti della blockchain stessa - per DAOBet - sono il tempo di finalizzazione e il ritardo dell'ultimo blocco finalizzato. Grazie a ciò, il team vede un aumento del consumo di memoria sui nodi durante l'esecuzione del benchmark, problemi con i validatori individuali
Punti importanti per condurre un gioco di validazione
A quanto pare, se vuoi consentire ufficialmente ai validatori di attaccare le macchine degli altri (ufficiosamente possono farlo comunque), devi formularlo separatamente legalmente come test di sicurezza, poiché secondo le leggi di alcuni paesi gli attacchi DDoS o di rete possono essere punito. Un’altra questione importante è come premiare i validatori. I premi naturali sono i token di progetto, che verranno trasferiti alla rete principale, ma anche una distribuzione massiccia di token a chiunque sia riuscito ad avviare un nodo non è l'opzione migliore. Molto probabilmente dovrai bilanciarti tra due opzioni estreme:
Distribuisci l'intero montepremi in base ai VP guadagnati
è molto democratico e consente a tutti coloro che hanno investito tempo e risorse nel gioco di validazione di guadagnare denaro
ma attira persone a caso verso il gioco senza un'infrastruttura preparata
Distribuisci il montepremi top-N ai validatori in base ai risultati del gioco
I vincitori saranno molto probabilmente i validatori che hanno resistito più costantemente durante il gioco e sono strettamente determinati a vincere
alcuni validatori non vorranno partecipare, valutando male le loro possibilità di vincita, soprattutto se tra i partecipanti ci sono validatori venerabili
Quale opzione scegliere dipende da te
C'è un altro punto: non è affatto un dato di fatto che dozzine di validatori si precipiteranno a partecipare al gioco alla tua chiamata, e di coloro che decidono di provare, non tutti installeranno e lanceranno nemmeno il nodo - di solito, in questa fase, i progetti hanno una documentazione piuttosto scarsa, si riscontrano errori e gli sviluppatori che lavorano sotto pressione in termini di tempo non rispondono alle domande molto rapidamente. Pertanto, prima di lanciare il gioco, è necessario prevedere anche delle azioni nel caso in cui non venga raggiunto il numero di validatori richiesto. In questo caso, all'inizio del gioco, i validatori mancanti vengono lanciati dal team di progetto, partecipano al consenso, ma non possono essere vincitori.
conclusione
In conclusione, ho provato a compilare da quanto sopra un elenco di ciò che è necessario pensare, realizzare e lanciare per condurre in modo efficace un gioco di validazione
Cosa devi fare per eseguire un vero gioco di convalida:
sviluppa la tua blockchain :)
- creare e creare un'interfaccia web e fornire una CLI per votare per i validatori
- assicurarsi che i parametri da un nodo di validazione in esecuzione possano essere inviati a un servizio centralizzato (ad esempio Prometheus)
- creare un server di raccolta metriche (Prometheus + Grafana) per il gioco di validazione
- capire come verranno calcolati i Punti Validatore (VP).
- sviluppare uno script pubblico che calcoli il VP del validatore in base ai dati della blockchain
- sviluppare un'interfaccia web per visualizzare i migliori validatori e lo stato del gioco dei validatori (quanto tempo manca alla fine, chi ha quanti VP, ecc.)
- sviluppare e automatizzare il lancio di un numero arbitrario dei propri nodi, progettare il processo di connessione dei validatori al gioco (quando e come disconnettere i propri nodi, inviare e rimuovere voti per essi)
- calcolare quanti token devono essere emessi e sviluppare un contratto faucet
- creare uno script di benchmark (trasferimenti di token, utilizzo massiccio dello spazio di archiviazione, utilizzo massiccio della rete)
- riunisci tutti i partecipanti in un'unica chat per una comunicazione rapida
- lancia la blockchain un po’ prima dell’inizio del gioco
- attendere il blocco di partenza, avviare il gioco
- testare la rete con diversi tipi di transazioni
- stendere una forchetta dura
- modificare l'elenco dei validatori
- ripetere i passaggi 13,14,15, XNUMX, XNUMX in ordini diversi, mantenendo la stabilità della rete
- aspetta il blocco finale, termina il gioco, conta i VP
Va detto che il gioco dei validatori è una storia nuova, ed è stato realizzato solo un paio di volte, quindi non bisogna prendere questo testo come una guida già pronta. Non ci sono analoghi nel moderno business IT: immagina che le banche, prima di lanciare un sistema di pagamento, competano tra loro per vedere chi sarà il migliore nel condurre le transazioni dei clienti. È improbabile che gli approcci tradizionali ti aiutino a creare grandi reti decentralizzate, quindi padroneggia nuovi modelli di business, esegui i tuoi giochi, identifica quelli meritevoli, premiali e mantieni i tuoi sistemi distribuiti funzionanti in modo rapido e stabile.
Fonte: habr.com