server<\/a> di nodi \u00e8 di per s\u00e9 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\u00e9 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\u00f2 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.<\/p>\n<\/p>\n
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. <\/p>\n
<\/p>\n
Validatori<\/h2>\n <\/p>\n
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 \u00e8 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\u00f9 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\u00e0 alla rete in avvio.<\/p>\n
<\/p>\n
La validazione \u00e8 un'attivit\u00e0 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\u00f2 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\u00f2 consentire ai validatori di compromettere l'economia sommersandola di denaro e privando gli altri utenti della rete.<\/p>\n
<\/p>\n
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\u00e0 di estrarre hash nelle reti proof-of-work, un nodo blockchain \u00e8 un grande servizio che occupa molta memoria, consuma una notevole quantit\u00e0 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 \u00e8 richiesto uno storage di almeno 50 Gb o pi\u00f9, e per i blocchi deve trattarsi di un SSD. Il database di stato delle blockchain che supportano contratti intelligenti pu\u00f2 gi\u00e0 superare i 64 Gb di memoria RAM. I server con le caratteristiche richieste sono piuttosto costosi; un nodo Ethereum o EOS pu\u00f2 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\u00e9 alcuni validatori possono trovarsi facilmente nell'emisfero opposto. Tuttavia, in momenti favorevoli, possedere un nodo-validator pu\u00f2 generare un reddito significativo (nel caso di EOS, fino a 10.000 $ al giorno).<\/p>\n
<\/p>\n
La validazione \u00e8 solo uno dei nuovi potenziali ruoli IT per imprenditori e aziende: man mano che i programmatori inventano algoritmi sempre pi\u00f9 sofisticati per premiare l'onest\u00e0 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 \u00e8 necessario pagare per l'archiviazione dei dati. <\/p>\n
<\/p>\n
Problemi di avvio della blockchain<\/h2>\n <\/p>\n
L'apertura della blockchain, che ha reso possibile la partecipazione libera al lavoro della rete di computer da qualsiasi paese e la semplicit\u00e0 di connessione alla rete per qualsiasi script kiddie secondo le istruzioni su GitHub, non \u00e8 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\u00e0 di cedere rapidamente i guadagni. Ci\u00f2 significa anche che il vostro validatore pu\u00f2 essere chiunque, anche un anonimo; per lui si pu\u00f2 votare proprio come per gli altri validatori (tuttavia, sar\u00e0 difficile per l'anonimo raccogliere voti dai portatori di interessi, quindi lasciamo le storie spaventose sulle criptovalute anonime ai politici). Tuttavia<\/p>\n
<\/p>\n
Il team del progetto ha il compito di ottenere nella propria rete chi nel futuro sar\u00e0 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\u00e0 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 \u00e8 inevitabile imbattersi in errori nel codice e nella configurazione dei nodi, e che la stabilit\u00e0 della rete dipende da quanto bene gli sviluppatori e i validatori collaboreranno nella risoluzione di problemi simili.<\/p>\n
<\/p>\n
Il team \u00e8 pronto a votare in mainnet per qualsiasi validatore, ma solo se sapessimo per chi, quali sono i buoni? Il pi\u00f9 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.<\/p>\n
<\/p>\n
In queste condizioni rimane solo una cosa \u2014 ci\u00f2 che risolve bene i problemi di tutti \u2014 un gioco, in cui sar\u00e0 possibile scegliere i migliori validatori, ma soprattutto \u2014 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 \u00e8 stata proposta come un gioco dai ragazzi del progetto Cosmos, e questa idea \u00e8 senza dubbio un modo eccellente per preparare la rete al lancio di un mainnet affidabile e a prova di guasto.<\/p>\n
<\/p>\n
Game of Validators<\/h2>\n <\/p>\n
Descriver\u00f2 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\u00f2 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 \u00e8 organizzato in modo diverso e di solito \u00e8 proprio in questa parte che la nuova blockchain differisce da quella madre; va detto che nel nostro caso EOS giustifica completamente \u201cOS\u201d nel suo nome, poich\u00e9 utilizziamo effettivamente EOS come sistema operativo di base per il dispiegamento di una versione modificata della blockchain per le esigenze di DAOBet.<\/p>\n
<\/p>\n
Descriver\u00f2 singoli problemi e come possono essere risolti nell'ambito del gioco. Immagina una rete in cui il tuo server pu\u00f2 essere attaccato apertamente, dove per mantenere la posizione di validatore \u00e8 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\u00e0 escluso dalla lista.<\/p>\n
<\/p>\n
Come scegliere i top vincitori?<\/h3>\n <\/p>\n
Il principale requisito tecnico per il gioco \u00e8 che i suoi risultati siano pubblicamente verificabili. Ci\u00f2 significa che i risultati del gioco: la TOP dei vincitori, devono essere formati rigorosamente sulla base di dati che qualsiasi partecipante pu\u00f2 verificare. In un sistema centralizzato potremmo misurare l'\u201cuptime\u201d di ciascun validatore e premiare quelli che sono stati pi\u00f9 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.<\/p>\n
<\/p>\n
Quindi la soluzione naturale \u00e8 che i vincitori devono essere determinati in base ai dati della blockchain, poich\u00e9 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 \u00e8 l'obiettivo principale dei validatori nel gioco. Nel nostro caso, la metrica di \"utilit\u00e0\" del validatore pi\u00f9 semplice, facilmente verificabile pubblicamente ed efficiente \u00e8 VP = numero_di_blocchi_prodotti_dal_validatore in un determinato periodo di tempo.<\/p>\n
<\/p>\n
Questa scelta semplice \u00e8 dovuta al fatto che la governance in EOS prevede gi\u00e0 molte problematiche emergenti, poich\u00e9 EOS \u00e8 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 \u00e8 un'ottima e semplice opzione.<\/p>\n
<\/p>\n
Negli altri blockchain, il modo di calcolare i Validator Points pu\u00f2 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\u00f9 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. <\/p>\n
<\/p>\n
Come modellare le reali condizioni di operativit\u00e0<\/h3>\n <\/p>\n
Il compito dei fondatori \u00e8 di testare i validatori in condizioni vicine alla realt\u00e0, senza avere alcun controllo centralizzato. Questo problema pu\u00f2 essere risolto tramite un contratto-faucet che distribuisce quantit\u00e0 uguali del token principale ai validatori e a chiunque sia interessato. Per ricevere i token sul bilancio, \u00e8 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\u00e9 stesso, promuovendosi in cima alla classifica. Questa attivit\u00e0 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.<\/p>\n
<\/p>\n
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\u00e0 di carico estremo. Pertanto, il team della blockchain dovr\u00e0 comunque scrivere benchmark aggiuntivi che consentano di caricare la rete. Un ruolo speciale in questo \u00e8 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\u00ec il volume delle transazioni - lanciando un flusso di tali transazioni in momenti casuali, il team testa simultaneamente la stabilit\u00e0 del codice e la resilienza dei validatori.<\/p>\n
<\/p>\n
Un altro argomento riguarda l'aggiornamento del codice dei nodi e l'esecuzione di hard fork. \u00c8 necessario che, in caso di bug, vulnerabilit\u00e0 o collusione di validator malevoli, i validator abbiano un piano d'azione gi\u00e0 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 \u00e8 complesso da realizzare, rendendo pi\u00f9 difficile il conteggio. Simulare una situazione di emergenza per l'applicazione dell'hard fork si pu\u00f2 fare artificialmente<\/p>\n
<\/p>\n
<\/p>\n
Nonostante la diffidenza tra i validator, ricevere informazioni aggiornate sullo stato della rete in modo tempestivo \u00e8 vantaggioso per tutti, per prendere decisioni pi\u00f9 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 \u00e8 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\u00f9 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 <\/p>\n
<\/p>\n
Punti importanti per lo svolgimento del gioco dei validator<\/h2>\n <\/p>\n
Come si \u00e8 rivelato, se desiderate autorizzare ufficialmente i validatori ad attaccare i dispositivi degli uni e degli altri (in modo non ufficiale possono gi\u00e0 farlo) \u2014 dovete formulare separatamente questo come test di sicurezza, poich\u00e9 secondo la legislazione di alcuni paesi si pu\u00f2 essere puniti per attacchi DDoS o attacchi di rete. Un'altra questione importante \u00e8 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 \u2014 non \u00e8 la soluzione migliore. Probabilmente dovrete bilanciare tra due opzioni estreme:<\/p>\n
<\/p>\n
Distribuire l'intero montepremi in base ai VP guadagnati
<\/p>\n
Distribuire il montepremi ai top-N validatori al termine del gioco
<\/p>\n
A quale opzione dare preferenza \u2014 sta a voi decidere <\/p>\n
<\/p>\n
C'\u00e8 anche un altro punto \u2014 non \u00e8 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 \u2014 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, \u00e8 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.<\/p>\n
<\/p>\n
Conclusione<\/h2>\n <\/p>\n
In conclusione, ho cercato di raccogliere dal suddetto un elenco di ci\u00f2 che bisogna inventare, fare e avviare per condurre efficacemente il gioco dei validatori<\/p>\n
<\/p>\n
Cosa bisogna fare per avviare un vero gioco di validatori:
<\/p>\n
\ncreare e lanciare un'interfaccia web e fornire CLI per votare sui validatori<\/li>\n fare in modo che le metriche da un nodo di validatore attivo possano essere inviate a un servizio centralizzato (per esempio Prometheus)<\/li>\n avviare un server di raccolta delle metriche (Prometheus + Grafana) per il gioco dei validatori<\/li>\n ideare come verranno calcolati i Validator Points (VP)<\/li>\n sviluppare uno script pubblico che calcoli i VP del validatore sulla base dei dati della blockchain<\/li>\n 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.)<\/li>\n 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)<\/li>\n calcolare quanti token devono essere distribuiti e sviluppare un contratto-faucet<\/li>\n creare uno script benchmark (trasferimenti di token, uso massiccio della memoria, uso massiccio della rete) <\/li>\n riunire tutti i partecipanti in una chat per una comunicazione rapida<\/li>\n lanciare la blockchain un po' prima dell'inizio del gioco<\/li>\n attendere il blocco iniziale, iniziare il gioco<\/li>\n testare la rete con diversi tipi di transazioni<\/li>\n eseguire un hard fork<\/li>\n modificare l'elenco dei validatori<\/li>\n ripetere i punti 13, 14, 15 in ordine diverso, mantenendo la stabilit\u00e0 della rete<\/li>\n attendere il blocco finale, terminare il gioco, calcolare i VP<\/li>\n<\/ul>\n<\/p>\n
Va detto che il gioco dei validatori \u00e8 una storia nuova e si \u00e8 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\u00e0 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.<\/p>\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0442\u0430\u043a, \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0430 alpha-\u0432\u0435\u0440\u0441\u0438\u044e \u0432\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430, \u0438 \u043f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c testnet, \u0430 \u0437\u0430\u0442\u0435\u043c \u0438 mainnet. \u0423 \u0432\u0430\u0441 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0439 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u0441 \u043d\u0435\u0437\u0430\u0432\u0438\u0441\u0438\u043c\u044b\u043c\u0438 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0445\u043e\u0440\u043e\u0448\u0435\u0439 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u044c\u044e, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e, \u0432\u044b \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 governance \u0438 \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0440\u0430 \u0431\u044b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0432 \u0434\u0435\u043b\u0435. \u0412 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u043a\u0440\u0438\u043f\u0442\u043e\u0430\u043d\u0430\u0440\u0445\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u043c\u0438\u0440\u0435, \u0432\u044b \u0432\u044b\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0435\u0442\u0435 \u0432 \u0441\u0435\u0442\u044c genesis block, \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u043d\u043e\u0434\u044b \u0438 \u0432\u0430\u043b\u0438\u0434\u0430\u0442\u043e\u0440\u044b \u0441\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39478","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t