Quindi, il tuo team ha completato la versione alpha della tua blockchain ed è ora di avviare la testnet, e poi la mainnet. Hai una vera blockchain, con partecipanti indipendenti, un buon modello economico, sicurezza, hai progettato la governance e ora è il momento di mettere tutto alla prova. In un ideale mondo crypto-anarchico, pubblicheresti il blocco genesis, il codice definitivo del nodo e i validatori avvierebbero tutto, attivando tutti i servizi ausiliari, e tutto accadrebbe da solo. Ma questo è un mondo immaginario; nella realtà, il team deve preparare una serie di software ausiliari e diverse operazioni per aiutare i validatori a lanciare una rete stabile. Questo è l'argomento di questo articolo.
Avviare reti basate su consensi tipo 'proof-of-stake', dove i validatori sono determinati dai voti dei possessori di token del sistema, è un compito piuttosto specifico, poiché anche l'avvio di sistemi tradizionali, gestiti in modo centralizzato, con decine e centinaia di server È una sfida complessa e il blockchain deve essere avviato grazie agli sforzi di partecipanti fedeli ma indipendenti. In una corporazione, durante il lancio, gli amministratori hanno accesso completo a tutte le macchine, ai log e al monitoraggio generale, mentre i validatori non permetteranno a nessuno di avvicinarsi ai loro server e, probabilmente, preferiranno costruire la propria infrastruttura in modo autonomo, poiché essa controlla l'accesso ai principali attivi del validatore: gli stake dei votanti. Questo comportamento è ciò che permette di costruire reti distribuite e sicure: l'indipendenza dei fornitori di cloud utilizzati, dei server virtuali e "baremetal", e dei diversi sistemi operativi rende così inefficaci gli attacchi a tale rete, grazie alla varietà di software utilizzato. Ad esempio, in Ethereum sono presenti due implementazioni principali del nodo, in Go e in Rust, e un attacco efficace per una implementazione non funziona sull'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 lanciare i propri computer dalla finestra e andarsene, senza che nulla si rompa. I validatori rimanenti devono continuare a sostenere in modo efficace il funzionamento della rete e a collegare nuovi validatori. Durante il lancio della rete, quando un validatore è in Europa, un secondo in Sud America e un terzo in Asia, è piuttosto difficile ottenere il funzionamento coordinato di decine di gruppi indipendenti e interessarli ai risultati.
Validatori
Immaginiamo il lancio di un ipotetico moderno blockchain (la maggior parte di quanto descritto si applica ai blockchain di qualsiasi moderna famiglia di blockchain: Ethereum, EOS, Polkadot, Cosmos e altri, che prevedono il consenso proof-of-stake. I principali attori di tali blockchain sono i team di validatori che installano server indipendenti, validando e producendo nuovi blocchi, ricevendo ricompense fornite dalla rete per coloro che partecipano al consenso. Per avviare nuove reti, sono richiesti diversi decine di validatori (tanti quanti ne possono raggiungere un consenso in modo più o meno efficace in pochi secondi), quindi il progetto annuncia la registrazione, attraverso la quale i validatori condividono informazioni pubbliche su di sé con gli utenti, convincendoli di essere pronti a gestire la rete avviata in modo qualitativo.
La validazione è un business che consente di valutare con grande precisione il potenziale guadagno di un validatore, trasferendo rapidamente le risorse tra progetti. In caso di successo della rete scelta, il validatore può diventare un membro a pieno titolo della DAO e contribuire allo sviluppo del progetto, oppure semplicemente fornire un eccellente servizio tecnico guadagnando denaro in modo del tutto trasparente. Nel calcolo della ricompensa per i validatori, i progetti cercano di tenere conto dei costi sostenuti dai validatori, rendendo la ricompensa per i blocchi tale da garantire la redditività di questo business senza compromettere l'economia della rete, evitando di inondarla di denaro e privare gli altri utenti della rete.
La gestione dei validatori aziendali richiede l'assicurazione di un'elevata resilienza dei servizi, il che implica un alto livello di competenza per DevOps e sviluppatori, oltre a costose risorse di calcolo. Anche senza la necessità di minare hash nelle reti proof-of-work, un nodo blockchain è un grande servizio che occupa molta memoria, consuma molta potenza di calcolo, valida e registra su disco, e trasmette grandi volumi di dati in rete. Attualmente, per memorizzare i log delle transazioni e le catene di blocchi per una blockchain con diverse migliaia di piccole transazioni per blocco, sono richiesti almeno 50 Gb di storage, e per i blocchi questo deve essere un SSD. Il database di stato delle blockchain che supportano smart contract può già superare i 64Gb di RAM. I server con le caratteristiche richieste sono piuttosto costosi; un nodo Ethereum o EOS può costare tra i 100 e i 200 $/mese. A questo si aggiunge l'aumento dei compensi per il lavoro continuativo di sviluppatori e DevOps, che durante la fase di avvio risolvono problemi anche di notte, dato che parte dei validatori può facilmente trovarsi nell'emisfero opposto. Tuttavia, in momenti favorevoli, possedere un nodo validatore può generare un reddito consistente (nel caso di EOS, fino a 10.000 $ al giorno).
La validazione è solo uno dei nuovi ruoli IT potenziali per imprenditori e aziende. Con l'invenzione di algoritmi sempre più sofisticati da parte degli sviluppatori, che premiano l'onestà e puniscono la frode e il furto, emergono servizi che svolgono funzioni di pubblicazione di dati importanti (oracoli), supervisione (slashing dei depositi e punizione dei trasgressori tramite la pubblicazione di prove di frodi), servizi di risoluzione delle dispute, assicurazioni e opzioni. Anche la raccolta dei rifiuti rappresenta un potenziale grande mercato nei sistemi di smart contract, dove è necessario pagare per la memorizzazione 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 facilità di connessione alla rete per chiunque seguendo le istruzioni su GitHub, non è sempre un vantaggio. La corsa a un nuovo token spesso spinge i validatori a "minare una nuova moneta all'inizio", sperando in un aumento del prezzo e nella possibilità di vendere rapidamente quanto guadagnato. Inoltre, ciò significa che il tuo validatore può essere chiunque, anche anonimo; per lui si può votare allo stesso modo di altri validatori (tuttavia, per l'anonimo sarà difficile raccogliere voti dai portatori di stake, quindi lasciamo le storie spaventose sulle criptovalute anonime ai politici). Tuttavia
Il team del progetto ha il compito di attrarre quelle persone in grado di garantire un funzionamento stabile dei nodi in futuro. Devono avere competenze in sicurezza, saper risolvere rapidamente i problemi, collaborare con altri validatori e lavorare insieme. La qualità di queste caratteristiche influisce direttamente sul token in cui i membri della rete intendono investire tempo e risorse. I fondatori competenti, valutando i rischi, comprendono bene che l'avvio di un software di una certa entità comporterà sicuramente errori nel codice e nella configurazione dei nodi, e che la stabilità della rete dipende da quanto bene gli sviluppatori e i validatori affronteranno insieme tali problematiche.
Il team è pronto a votare in mainnet per qualsiasi validatore, ma sarebbe bene avere idea di chi siano, quali siano i buoni. Il validatore con il portafoglio più grande? Attualmente è quasi inesistente. In base ai profili del team su Linkedin? I DevOps o esperti di sicurezza non condivideranno alcun profilo su Linkedin. Basandosi su dichiarazioni in chat, post e aiuto reciproco durante la fase di preparazione? Questo è valido, ma soggettivo e impreciso.
In queste condizioni, rimane solo una cosa: quella che risolve i problemi di tutti — un gioco in cui sarà possibile scegliere i migliori validatori, ma soprattutto — testare la robustezza della blockchain e condurre un test bellico su larga scala della blockchain in condizioni di utilizzo attivo, cambiamenti nel consenso, apparizione e correzione di errori. Questa procedura è stata presentata per la prima volta come un gioco dai ragazzi del progetto Cosmos, e quest'idea è senza dubbio un ottimo modo per preparare la rete al lancio di un mainnet affidabile e robusto.
Game of Validators
Descriverò il funzionamento dei validatori come lo abbiamo progettato per la blockchain DAO.Casino (DAOBet), basata su un fork di EOS chiamato Haya, che ha un meccanismo di governance simile. I validatori vengono selezionati attraverso votazioni da qualsiasi account, in cui una parte del saldo utilizzato per votare per un validatore viene congelata. Qualsiasi account che detiene il token principale BET può votare per il validatore scelto usando qualsiasi parte del proprio saldo. I voti vengono sommati e alla fine si costruisce una classifica dei validatori. In diverse blockchain, questo processo è organizzato in modi differenti, e di solito è proprio in questa fase che una nuova blockchain si distingue dalla sua origine. Va detto che nel nostro caso EOS giustifica appieno l'acronimo 'OS' nel suo nome; utilizziamo realmente EOS come sistema operativo di base per implementare una versione modificata della blockchain per le esigenze di DAOBet.
Descriverò problemi specifici e come affrontarli all'interno del gioco. Immaginiamo una rete in cui il tuo server possa essere attaccato apertamente, dove è necessario interagire continuamente con la rete per mantenere la posizione di validatore, promuovendo il proprio validatore e assicurandosi che produca blocchi e che questi siano consegnati in tempo agli altri validatori; altrimenti, il validatore verrà rimosso dalla lista.
Come scegliere i vincitori top?
Il principale requisito tecnico per il gioco è che i suoi risultati siano pubblicamente verificabili. Questo significa che i risultati del gioco: i vincitori TOP, devono essere formati esclusivamente sulla base di dati che può verificare qualsiasi partecipante. In un sistema centralizzato potremmo misurare il 'uptime' di ogni validatore e premiare quelli che sono stati online di più o che hanno gestito il massimo del traffico di rete. È possibile raccogliere dati sull'uso della CPU, della memoria e premiare coloro che hanno lavorato con impegno. Ma ogni raccolta di metriche implica l'esistenza di un centro di raccolta, e inoltre, i nodi sono tutti indipendenti e possono comportarsi come vogliono e inviare qualsiasi dato.
Pertanto, la soluzione naturale è che i vincitori siano determinati dai dati della blockchain, poiché da essa è possibile vedere quali validatori hanno prodotto quali blocchi e quali transazioni sono state incluse. Abbiamo chiamato questo numero Validator Points (VP), e guadagnarli è l'obiettivo principale dei validatori nel gioco. Nel nostro caso, la metrica di "utilità" del validatore più semplice, facilmente verificabile pubblicamente ed efficace è VP = numero_di_blocchi_prodotti_dal_validatore in un certo periodo di tempo.
Questa scelta semplice è giustificata dal fatto che la governance in EOS prevede già molte problematiche, poiché EOS è l'erede di tre generazioni di blockchain operativi con una vasta esperienza nella gestione complessa della rete, e praticamente qualsiasi problema del validatore con la rete, il processore o il disco porta solo a un problema: firma meno blocchi e riceve un compenso inferiore per il lavoro, il che ci riporta ai numeri di blocchi firmati: per EOS è un'ottima e semplice soluzione.
Negli altri blockchain, il metodo per calcolare i Validator Points può variare; ad esempio, per i consensi basati su pBFT (Tendermint/Cosmos, consenso Aura di Parity Substrate), dove ogni blocco deve essere firmato da più validatori, ha senso contare le firme individuali dei validatori anziché i blocchi. Potrebbe anche avere senso considerare i turni di consenso non conclusi, che consumano le risorse di altri validatori. In generale, ciò dipende fortemente dal tipo di consenso.
Come simulare le condizioni reali di esercizio
Il compito dei fondatori è quello di testare i validatori in condizioni il più simili possibile alla realtà, senza alcun controllo centralizzato. Questo problema può essere risolto con un contratto faucet, che distribuisce quantità pari del token principale ai validatori e a chiunque altro ne faccia richiesta. Per ricevere i token sul proprio saldo, è necessario effettuare una transazione e assicurarsi che la rete la includa in un blocco. In questo modo, il validatore deve costantemente rifornire il proprio saldo con nuovi token e votare per se stesso, facendosi così strada verso la vetta. Questa attività crea un carico costante sulla rete e i parametri possono essere adeguati in modo tale da rendere il flusso di richieste sufficientemente significativo per un test completo della rete. Pertanto, pianificate il contratto faucet in anticipo, come uno strumento fondamentale per il lancio della rete, e iniziate a definire i suoi parametri il prima possibile.
La richiesta di token dal faucet e il voto dei validatori non emulano del tutto in modo onesto il funzionamento della blockchain, soprattutto in condizioni di alta intensità. Pertanto, il team blockchain dovrà comunque redigere benchmark aggiuntivi per testare la rete. Un ruolo particolare in questo è svolto da contratti smart appositamente creati in anticipo, che permettono di testare singole sottosistemi. Per il test dello storage, il contratto memorizza nel blockchain dati casuali, mentre per verificare le risorse di rete, il contratto di test richiede un grande volume di dati in ingresso, espandendo così il volume delle transazioni: avviando un flusso di tali transazioni in momenti casuali, il team testa simultaneamente la stabilità del codice e la resilienza dei validatori.
Отдельным вопросом стоит обновление кода нод и проведение хардфорков. Требуется, чтобы в случае появления бага, уязвимости, сговора злонамеренных валидаторов, валидаторы имели бы план действий, уже отработанный в игре валидаторов. Здесь можно придумывать схемы начисления VP за быстрое применение хардфорка, к примеру штрафуя всех валидаторов, кто еще не накатил новую версию кода ноды, но это сложно реализовать, усложняет подсчет. Сэмулировать ситуацию экстренного применения хардфорка можно искусственно “сломав” блокчейн на заданном блоке. Производство блоков останавливается, и в итоге в выигрыше окажутся те, кто раньше включится, и начнет подписывать блоки, так что VP на основе числа подписанных блоков здесь хорошо подходит.
Как информировать участников о состоянии сети и чинить ошибки
Nonostante la sfiducia tra i validatori, ricevere tempestivamente informazioni aggiornate sullo stato della rete è vantaggioso per tutti, per prendere decisioni più rapide. Pertanto, il team del progetto sta implementando un servizio per raccogliere e visualizzare numerose metriche dai server dei validatori, permettendo di vedere la situazione contemporaneamente per tutta la rete e di identificare rapidamente cosa sta accadendo. Inoltre, è nel nostro interesse, sia per i validatori che per il progetto, che il team corrisponda rapidamente agli errori trovati. Perciò, oltre alla raccolta delle metriche, ha senso avviare immediatamente la raccolta dei log e dei dati sugli errori dalle macchine dei validatori su una macchina accessibile agli sviluppatori della blockchain. Qui, nessuno ha interesse a distorcere le informazioni, per cui questi servizi vengono implementati dal team del progetto e sono affidabili. È utile raccogliere metriche di sistema dai validatori e, necessariamente, le metriche più importanti della blockchain — per DAOBet, questo significa il tempo di finalizzazione e il ritardo dell'ultimo blocco finalizzato. Grazie a questo, il team può monitorare l'aumento del consumo di memoria sui nodi durante l'esecuzione del benchmark e problemi specifici dei validatori.
Punti chiave per lo svolgimento del gioco dei validatori
Come si è scoperto, se desiderate autorizzare ufficialmente i validatori ad attaccare le macchine l'una dell'altra (in modo informale possono già farlo) — è necessario formulare giuridicamente questo come un test di sicurezza, poiché secondo la legislazione di alcuni paesi si possono subire sanzioni per DDoS o attacchi di rete. Un'altra questione importante è come premiare i validatori. I premi naturali sono i token del progetto, che verranno trasferiti nel mainnet, ma una distribuzione massiccia di token a chiunque riesca a avviare un nodo — non è una soluzione ottimale. Probabilmente dovrete bilanciare tra due opzioni estreme:
Distribuire l'intero montepremi in base ai VP guadagnati
è molto democratico e consente a tutti coloro che hanno investito tempo e risorse nel gioco dei validatori di guadagnare
ma attira al gioco persone casuali senza un'infrastruttura preparata
Distribuire il montepremi ai top-N validatori alla fine del gioco
probabilmente i vincitori saranno i validatori che sono riusciti a rimanere stabili durante il gioco, molto motivati a vincere
alcuni validatori potrebbero non voler partecipare, valutando scoraggiante le loro possibilità di vincere, specialmente se tra i partecipanti ci sono validatori esperti
La scelta del'opzione da preferire è a vostra discrezione
C'è anche un altro aspetto: non è affatto sicuro che decine di validatori rispondano al vostro invito a partecipare al gioco, e tra coloro che decidono di provare, non tutti installeranno e avvieranno un nodo — di solito, in questa fase, i progetti hanno documentazione piuttosto scarsa, si incontrano errori, e gli sviluppatori che lavorano sotto pressione non rispondono alle domande in modo molto tempestivo. Pertanto, prima di avviare il gioco, è necessario anche prevedere delle azioni nel caso in cui non si raggiunga il numero necessario di validatori. In questo caso, all'inizio del gioco, i validatori mancanti possono essere avviati dal team del progetto, partecipano al consenso, ma non possono essere vincitori.
Conclusione
In conclusione, ho cercato di raccogliere da quanto descritto sopra un elenco di ciò che è necessario ideare, realizzare e avviare per un'efficace conduzione del gioco dei validatori
Cosa bisogna fare per avviare un vero gioco di validatori:
sviluppare la propria blockchain 🙂
- creare e avviare un'interfaccia web e fornire una CLI per la votazione dei validatori
- rendere possibile l'invio delle metriche dalla nodi validatore attivi a un servizio centralizzato (ad esempio Prometheus)
- avviare un server per la raccolta delle metriche (Prometheus + Grafana) per il gioco dei validatori
- ideare come verranno conteggiati i Punti Validator (VP)
- sviluppare uno script pubblico per il calcolo dei VP del validatore basato sui dati della blockchain
- sviluppare un'interfaccia web per visualizzare la top list dei validatori e lo stato del gioco dei validatori (quanto tempo rimane, chi ha quanti VP, ecc.)
- sviluppare e automatizzare il lancio di un numero arbitrario di nodi propri, progettare il processo di connessione dei validatori al gioco (quando e come disconnettere le proprie nodi, esprimere e ritirare voti per loro)
- calcolare quanti token devono essere distribuiti e sviluppare un contratto-faucet
- creare uno script di benchmark (trasferimenti di token, utilizzo massiccio dello storage, utilizzo 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, avviare il gioco
- testare la rete con diversi tipi di transazioni
- implementare 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, conteggiare i VP
Va detto che il gioco dei validatori è una storia nuova e si è svolto solo un paio di volte, quindi non bisogna considerare questo testo come una guida definitiva. Non esistono analoghi nel moderno settore IT — immaginate che le banche si sfidino tra loro prima di lanciare un sistema di pagamenti, per vedere chi gestirà meglio le transazioni dei clienti. Gli approcci tradizionali difficilmente vi aiuteranno a costruire grandi reti decentralizzate, quindi esplorate nuovi modelli di business, organizzate i vostri giochi, identificate i meritevoli, premiateli e fate in modo che i vostri sistemi distribuiti funzionino in modo rapido e stabile.
Fonte: habr.com
