Quindi, il tuo team ha completato la versione alpha della tua blockchain e ora è il momento di lanciare il testnet e poi il mainnet. Hai una vera blockchain, con partecipanti indipendenti, un buon modello economico, sicurezza, hai progettato la governance e ora è il momento di mettere tutto in pratica. In un perfetto mondo crypto-anarchico, pubblichi il blocco di genesis in rete, il codice definitivo del nodo e i validatori avviano tutto da soli, attivano tutti i servizi di supporto e tutto accade da solo. Ma questo è in un mondo immaginario; nella realtà, il team deve preparare un bel po' di software ausiliario e diverse operazioni per aiutare i validatori a lanciare una rete sostenibile. Di questo parla questo articolo.
Lanciare reti basate su consensi tipo 'proof-of-stake', dove i validatori vengono determinati dai voti dei detentori di token del sistema, è un'attività piuttosto specifica, infatti anche il lancio di sistemi tradizionali, gestiti centralmente, con decine e centinaia server di nodi è di per sé un compito complesso, e la blockchain deve essere avviata con gli sforzi di partecipanti leali, ma indipendenti. E, se nelle aziende, al lancio gli amministratori hanno accesso completo a tutte le macchine, ai log, al monitoraggio complessivo, i validatori non permetteranno a nessuno di avvicinarsi ai loro server e, molto probabilmente, preferiranno costruire la propria infrastruttura in autonomia, poiché essa controlla l'accesso agli attivi principali del validatore: gli stake dei votanti. Questo tipo di comportamento consente di costruire reti sicure e distribuite: l'indipendenza dei fornitori cloud utilizzati, dei server virtuali e 'bare metal', dei diversi sistemi operativi, tutto ciò rende gli attacchi a una rete di questo tipo estremamente inefficaci: si utilizza troppo software diverso. Ad esempio, in Ethereum sono utilizzate due implementazioni principali del nodo, in Go e in Rust, e un attacco efficace per una implementazione non funziona per l'altra.
Pertanto, tutti i processi di avvio e gestione delle blockchain devono essere organizzati in modo tale che qualsiasi validatore, o anche un piccolo gruppo di validatori, possa in qualsiasi momento buttare i propri computer dalla finestra e andarsene, senza che nulla si rompa e i validatori rimanenti possano continuare a sostenere efficacemente il funzionamento della rete e collegare nuovi validatori. All'avvio della rete, quando un validatore si trova in Europa, un altro in Sud America e un terzo in Asia, risulta piuttosto difficile ottenere un funzionamento coordinato di diverse decine di gruppi indipendenti e coinvolgerli nel risultato.
Validatori
Immaginiamo il lancio di una moderna blockchain ipotetica (gran parte di quanto descritto si applica alle blockchain basate su qualsiasi moderno insieme di blockchain: Ethereum, EOS, Polkadot, Cosmos e altre, in cui è previsto un consenso proof-of-stake). I principali protagonisti di queste blockchain sono le squadre di validatori, che si occupano di installare i propri server indipendenti, validando e producendo nuovi blocchi, e ricevendo le ricompense previste dalla rete per coloro che partecipano al consenso. Per l'avvio di nuove reti sono richiesti diversi decine di validatori (tanti quanti ne possono raggiungere più o meno efficacemente il consenso in pochi secondi), quindi il progetto annuncia la registrazione, in cui i validatori condividono informazioni pubbliche su di loro con gli utenti, convincendoli che intendono fornire un servizio di alta qualità alla rete in avvio.
La validazione è un'attività che consente di valutare con grande precisione il potenziale guadagno di un validatore, spostare rapidamente le risorse tra i progetti, e in caso di successo della rete scelta, il validatore può contribuire al progetto come partecipante attivo del DAO e responsabile, oppure semplicemente offrire un ottimo servizio tecnico in cambio di denaro guadagnato in modo completamente trasparente. Nel calcolo della ricompensa per i validatori, i progetti cercano di considerare le spese dei validatori e di stabilire una ricompensa per blocco tale che questo business sia redditizio, senza però consentire ai validatori di compromettere l'economia sommersandola di denaro e privando gli altri utenti della rete.
Il business dei validatori richiede garanzie di alta resilienza dei servizi, il che implica un elevato livello di preparazione per sviluppatori e DevOps, oltre a risorse di calcolo non economiche. Anche senza la necessità di estrarre hash nelle reti proof-of-work, un nodo blockchain è un grande servizio che occupa molta memoria, consuma una notevole quantità di calcoli, valida, registra su disco e restituisce alla rete grandi volumi di dati. Per l'archiviazione del log delle transazioni e delle catene di blocchi per un blockchain con diverse migliaia di piccole transazioni nel blocco, ora è richiesto uno storage di almeno 50 Gb o più, e per i blocchi deve trattarsi di un SSD. Il database di stato delle blockchain che supportano contratti intelligenti può già superare i 64 Gb di memoria RAM. I server con le caratteristiche richieste sono piuttosto costosi; un nodo Ethereum o EOS può costare da 100 a 200 $/mese. A questo si aggiunge un aumento della retribuzione per il lavoro a tempo pieno degli sviluppatori e dei DevOps, che durante il lancio risolvono problemi anche di notte, poiché alcuni validatori possono trovarsi facilmente nell'emisfero opposto. Tuttavia, in momenti favorevoli, possedere un nodo-validator può generare un reddito significativo (nel caso di EOS, fino a 10.000 $ al giorno).
La validazione è solo uno dei nuovi potenziali ruoli IT per imprenditori e aziende: man mano che i programmatori inventano algoritmi sempre più sofisticati per premiare l'onestà e punire la frode e il furto, stanno emergendo servizi che svolgono funzioni di pubblicazione di dati importanti (oracoli), supervisionano (slashing dei depositi e punizione dei trasgressori tramite pubblicazione della prova di frode), servizi di risoluzione delle controversie, assicurazioni e opzioni; anche la garbage collection rappresenta un potenziale grande mercato nei sistemi di contratti intelligenti, dove è necessario pagare per l'archiviazione dei dati.
Problemi di avvio della blockchain
L'apertura della blockchain, che ha reso possibile la partecipazione libera al lavoro della rete di computer da qualsiasi paese e la semplicità di connessione alla rete per qualsiasi script kiddie secondo le istruzioni su GitHub, non è sempre un vantaggio. La corsa a un nuovo token spesso induce i validatori a "minare una nuova moneta all'inizio", nella speranza di un aumento del valore e della possibilità di cedere rapidamente i guadagni. Ciò significa anche che il vostro validatore può essere chiunque, anche un anonimo; per lui si può votare proprio come per gli altri validatori (tuttavia, sarà difficile per l'anonimo raccogliere voti dai portatori di interessi, quindi lasciamo le storie spaventose sulle criptovalute anonime ai politici). Tuttavia
Il team del progetto ha il compito di ottenere nella propria rete chi nel futuro sarà in grado di garantire il funzionamento stabile dei nodi, comprende la sicurezza, sa risolvere problemi rapidamente, cooperare con altri validatori e agire insieme: da queste qualità dipende in modo significativo il valore del token in cui i partecipanti della rete intendono investire tempo e risorse. I fondatori sensati, valutando i rischi, comprendono bene che al lancio di un software di tale portata è inevitabile imbattersi in errori nel codice e nella configurazione dei nodi, e che la stabilità della rete dipende da quanto bene gli sviluppatori e i validatori collaboreranno nella risoluzione di problemi simili.
Il team è pronto a votare in mainnet per qualsiasi validatore, ma solo se sapessimo per chi, quali sono i buoni? Il più grande portafoglio? Attualmente quasi nessuno lo ha. Per i profili del team su Linkedin? I devops esperti o gli esperti di sicurezza non vi forniranno alcun profilo su Linkedin. In base alle dichiarazioni in chat, post e aiuti agli altri nella fase di preparazione? Bene, ma soggettivo e impreciso.
In queste condizioni rimane solo una cosa — ciò che risolve bene i problemi di tutti — un gioco, in cui sarà possibile scegliere i migliori validatori, ma soprattutto — testare la blockchain in termini di robustezza e condurre un test completo della blockchain in condizioni di utilizzo attivo, cambiamenti nel consenso, apparizione e correzione degli errori. Per la prima volta, questa procedura è stata proposta come un gioco dai ragazzi del progetto Cosmos, e questa idea è senza dubbio un modo eccellente per preparare la rete al lancio di un mainnet affidabile e a prova di guasto.
Game of Validators
Descriverò il gioco dei validatori come lo abbiamo progettato per la blockchain DAO.Casino (DAOBet) basata sul fork di EOS, chiamato Haya, che ha un meccanismo di governance simile: i validatori vengono scelti attraverso votazioni da qualsiasi account, in cui una parte del saldo utilizzato per votare per il validatore viene congelata. Qualsiasi account con il token principale BET nel proprio saldo può votare per un validatore scelto con qualsiasi parte del proprio saldo. I voti vengono sommati e alla fine si crea una classifica dei validatori. In diverse blockchain, questo processo è organizzato in modo diverso e di solito è proprio in questa parte che la nuova blockchain differisce da quella madre; va detto che nel nostro caso EOS giustifica completamente “OS” nel suo nome, poiché utilizziamo effettivamente EOS come sistema operativo di base per il dispiegamento di una versione modificata della blockchain per le esigenze di DAOBet.
Descriverò singoli problemi e come possono essere risolti nell'ambito del gioco. Immagina una rete in cui il tuo server può essere attaccato apertamente, dove per mantenere la posizione di validatore è necessario interagire continuamente con la rete, promuovendo il proprio validatore e assicurandosi che questo produca blocchi e che vengano consegnati puntualmente agli altri validatori; altrimenti, il validatore verrà escluso dalla lista.
Come scegliere i top vincitori?
Il principale requisito tecnico per il gioco è che i suoi risultati siano pubblicamente verificabili. Ciò significa che i risultati del gioco: la TOP dei vincitori, devono essere formati rigorosamente sulla base di dati che qualsiasi partecipante può verificare. In un sistema centralizzato potremmo misurare l'“uptime” di ciascun validatore e premiare quelli che sono stati più a lungo online o che hanno gestito il massimo del traffico di rete. Si possono raccogliere dati sul carico della CPU, sulla memoria e premiare coloro che hanno lavorato meritevolmente. Ma ogni raccolta di metriche implica l'esistenza di un centro di raccolta, e le nodi sono tutte indipendenti e possono comportarsi come vogliono, inviando qualsiasi dato.
Quindi la soluzione naturale è che i vincitori devono essere determinati in base ai dati della blockchain, poiché attraverso di essa possiamo vedere quale validatore ha prodotto quale blocco e quali transazioni sono state incluse. Abbiamo chiamato questo numero Validator Points (VP), e il loro guadagno è l'obiettivo principale dei validatori nel gioco. Nel nostro caso, la metrica di "utilità" del validatore più semplice, facilmente verificabile pubblicamente ed efficiente è VP = numero_di_blocchi_prodotti_dal_validatore in un determinato periodo di tempo.
Questa scelta semplice è dovuta al fatto che la governance in EOS prevede già molte problematiche emergenti, poiché EOS è l'erede di tre generazioni di blockchain funzionanti, con grande esperienza nella gestione complessa della rete, e praticamente qualsiasi problema di un validatore con la rete, il processore o il disco porta a un'unica problematica: firma meno blocchi e riceve una minore retribuzione per il lavoro svolto, il che ci riconduce semplicemente al numero di blocchi firmati, che per EOS è un'ottima e semplice opzione.
Negli altri blockchain, il modo di calcolare i Validator Points può essere diverso; ad esempio, per i consorzi basati su pBFT (Tendermint/Cosmos, il consenso Aura di Parity Substrate), dove ogni blocco deve essere firmato da più validatori, ha senso contare le singole firme dei validatori piuttosto che i blocchi; potrebbe anche avere senso considerare i round di consenso non completi, che consumano risorse di altri validatori; in generale, questo dipende fortemente dal tipo di consenso.
Come modellare le reali condizioni di operatività
Il compito dei fondatori è di testare i validatori in condizioni vicine alla realtà, senza avere alcun controllo centralizzato. Questo problema può essere risolto tramite un contratto-faucet che distribuisce quantità uguali del token principale ai validatori e a chiunque sia interessato. Per ricevere i token sul bilancio, è necessario formare una transazione e ottenere che la rete la includa in un blocco. In questo modo, il validatore per vincere deve costantemente aumentare il proprio bilancio con nuovi token e votare per sé stesso, promuovendosi in cima alla classifica. Questa attività crea un carico costante sulla rete, e i parametri possono essere impostati in modo che il flusso di richieste sia adeguatamente significativo per un test completo della rete. Pertanto, pianifica il contratto-faucet in anticipo come uno strumento importante per l'avvio della rete e inizia a definire i suoi parametri in anticipo.
La richiesta di token dal faucet e il voto dei validatori comunque non simulano completamente in modo onesto il funzionamento della blockchain, soprattutto in modalità di carico estremo. Pertanto, il team della blockchain dovrà comunque scrivere benchmark aggiuntivi che consentano di caricare la rete. Un ruolo speciale in questo è rivestito dai contratti intelligenti creati appositamente in anticipo, che permettono di testare un sotto-sistema specifico. Per testare lo storage, il contratto salva dati casuali nella blockchain, mentre per verificare le risorse di rete il contratto di test richiede un grande volume di dati in ingresso, gonfiando così il volume delle transazioni - lanciando un flusso di tali transazioni in momenti casuali, il team testa simultaneamente la stabilità del codice e la resilienza dei validatori.
Un altro argomento riguarda l'aggiornamento del codice dei nodi e l'esecuzione di hard fork. È necessario che, in caso di bug, vulnerabilità o collusione di validator malevoli, i validator abbiano un piano d'azione già testato nel contesto del gioco dei validator. Qui si possono inventare schemi di attribuzione di VP per un rapido utilizzo dell'hard fork, ad esempio penalizzando tutti i validator che non hanno ancora aggiornato la nuova versione del codice del nodo, ma questo è complesso da realizzare, rendendo più difficile il conteggio. Simulare una situazione di emergenza per l'applicazione dell'hard fork si può fare artificialmente
Come informare i partecipanti sullo stato della rete e correggere gli errori
Nonostante la diffidenza tra i validator, ricevere informazioni aggiornate sullo stato della rete in modo tempestivo è vantaggioso per tutti, per prendere decisioni più rapidamente. Pertanto, il team del progetto avvia un servizio per raccogliere e visualizzare una serie di metriche dai server dei validator, consentendo di vedere la situazione contemporaneamente per l'intera rete e di identificare rapidamente cosa sta accadendo. Inoltre, sia per i validator che per il progetto è vantaggioso che il team del progetto corregga rapidamente gli errori trovati. Pertanto, oltre alla raccolta di metriche, ha senso avviare immediatamente la raccolta di log e dati sugli errori dai nodi dei validator su una macchina accessibile agli sviluppatori della blockchain. Qui nessuno ha interesse a distorcere le informazioni, quindi questi servizi sono avviati dal team del progetto e sono affidabili. Ha senso raccogliere metriche di sistema dai validator e, necessariamente, le metriche più importanti della blockchain stessa: per DAOBet, si tratta del tempo di finalizzazione e dell'arretrato dell'ultimo blocco finalizzato. Grazie a questo, il team vede l'aumento del consumo di memoria sui nodi durante l'esecuzione del benchmark e i problemi di alcuni validator
Punti importanti per lo svolgimento del gioco dei validator
Come si è rivelato, se desiderate autorizzare ufficialmente i validatori ad attaccare i dispositivi degli uni e degli altri (in modo non ufficiale possono già farlo) — dovete formulare separatamente questo come test di sicurezza, poiché secondo la legislazione di alcuni paesi si può essere puniti per attacchi DDoS o attacchi di rete. Un'altra questione importante è come premiare i validatori. I premi naturali sono i token del progetto, che saranno trasferiti in mainnet, ma una distribuzione massiccia di token a chiunque riesca a lanciare un nodo — non è la soluzione migliore. Probabilmente dovrete bilanciare tra due opzioni estreme:
Distribuire l'intero montepremi in base ai VP guadagnati
è molto democratico e consente di guadagnare a tutti coloro che hanno investito tempo e risorse nel gioco dei validatori
ma attira nel gioco persone casuali senza un'infrastruttura preparata
Distribuire il montepremi ai top-N validatori al termine del gioco
i vincitori saranno probabilmente i validatori che hanno mantenuto la maggiore stabilità durante il gioco, molto motivati a vincere
una parte dei validatori potrebbe non voler partecipare, valutando basse le proprie possibilità di vincita, soprattutto se tra i partecipanti ci sono validatori esperti
A quale opzione dare preferenza — sta a voi decidere
C'è anche un altro punto — non è affatto certo che decine di validatori si lancino a partecipare al gioco su vostro invito, e di quelli che decidono di provare, non tutti installeranno e avvieranno un nodo — di solito, in questa fase i progetti hanno una documentazione piuttosto scarsa, si presentano errori e gli sviluppatori, che stanno lavorando sotto pressione, rispondono alle domande non proprio tempestivamente. Pertanto, prima di avviare il gioco, è necessario prevedere anche le azioni da intraprendere se non si riesce a raggiungere il numero richiesto di validatori. In tal caso, all'inizio del gioco, i validatori mancanti vengono avviati dal team del progetto, partecipano al consenso, ma non possono essere vincitori.
Conclusione
In conclusione, ho cercato di raccogliere dal suddetto un elenco di ciò che bisogna inventare, fare e avviare per condurre efficacemente il gioco dei validatori
Cosa bisogna fare per avviare un vero gioco di validatori:
sviluppare il proprio blockchain 🙂
- creare e lanciare un'interfaccia web e fornire CLI per votare sui validatori
- fare in modo che le metriche da un nodo di validatore attivo possano essere inviate a un servizio centralizzato (per esempio Prometheus)
- avviare un server di raccolta delle metriche (Prometheus + Grafana) per il gioco dei validatori
- ideare come verranno calcolati i Validator Points (VP)
- sviluppare uno script pubblico che calcoli i VP del validatore sulla base dei dati della blockchain
- sviluppare un'interfaccia web per visualizzare il top dei validatori e lo stato del gioco dei validatori (quanto tempo manca alla fine, quanti VP ha ciascuno, ecc.)
- sviluppare e automatizzare il lancio di un numero arbitrario di nodi propri, progettare il processo di collegamento dei validatori al gioco (quando e come disattivare i propri nodi, esprimere e ritirare voti per loro)
- calcolare quanti token devono essere distribuiti e sviluppare un contratto-faucet
- creare uno script benchmark (trasferimenti di token, uso massiccio della memoria, uso massiccio della rete)
- riunire tutti i partecipanti in una chat per una comunicazione rapida
- lanciare la blockchain un po' prima dell'inizio del gioco
- attendere il blocco iniziale, iniziare il gioco
- testare la rete con diversi tipi di transazioni
- eseguire un hard fork
- modificare l'elenco dei validatori
- ripetere i punti 13, 14, 15 in ordine diverso, mantenendo la stabilità della rete
- attendere il blocco finale, terminare il gioco, calcolare i VP
Va detto che il gioco dei validatori è una storia nuova e si è svolto solo un paio di volte, quindi non si dovrebbe interpretare questo testo come una guida definitiva. Non ci sono analoghi nel moderno business IT: immaginate che le banche, prima di lanciare un sistema di pagamento, competano tra loro su chi riuscirà a gestire le transazioni dei clienti in modo migliore. Gli approcci tradizionali difficilmente vi aiuteranno a creare grandi reti decentralizzate, quindi apprendere nuovi modelli di business, organizzare i vostri giochi, definire chi merita, premiarli e fare in modo che i vostri sistemi distribuiti funzionino velocemente e stabilmente.
Fonte: habr.com
