Come abbiamo generato 96 verificatori eletti

Pubblicato il

(Indika) (5 settembre 2019)

Lultima volta che ho pubblicato un articolo è stato cinque anni fa, ed era intitolato: Cucinare un server web con Chef . Cinque anni sono tanti per non scrivere. Non è che avessi perso interesse per largomento; invece stavo imparando tranquillamente dai migliori.

Largomento della discussione, tuttavia, non è cambiato, tranne per il fatto che ora è un ordine di grandezza più grande. Allora stavo preparando un singolo server web e ora sto generando 96 Elected Verifier (EV).

Perché 96?

In Unification, stiamo cambiando lalgoritmo di consenso sottostante di Ethereum. La nostra implementazione della governance distribuita del palo coinvolge quattro gruppi di 24 veicoli elettrici, che ruotano allinterno e allesterno della convalida dei blocchi. La governance di queste rotazioni è facilitata attraverso un processo di votazione e staking. Il risultato finale è una rete di consorzi più distribuita.

Teorizzare questo argomento su white paper e simulazioni non può che portarci lontano. Il modo migliore per andare avanti è produrlo, giocarci e sperimentare eventuali carenze.

Consegna continua

Vogliamo essere in grado di valutare rapidamente le nostre idee . Lo sviluppo basato sui test non deve essere limitato alla scrittura di unit test.

Per ogni Git SHA, vogliamo far girare qualsiasi versione della nostra Mainchain eseguendo un singolo comando, valutarne lo stato e quindi fare affinamenti al suo DNA.

Vogliamo continuare a perfezionare questo processo, finché non crediamo di avere qualcosa pronto per la produzione. Il processo di sviluppo del software non è altro che questa semplice iterazione:

Più complesso diventa un sistema, più difficile diventa ciascuna di queste parti. Istanziare 96 veicoli elettrici è un problema non banale ed è il fulcro di questo articolo.

Definizione

Iniziamo definendo cosa vogliamo distribuire. Un cluster istanziato sarà composto principalmente da EV, dove alcuni di essi hanno RPC abilitato e altri no. Il cluster può anche includere un faucet UND, un block explorer e forse anche un nodo di monitoraggio.

Questi cluster sono specificati da file JSON e lo scopo dello stack di provisioning può renderli tali.

Ogni nodo allinterno del cluster necessita di un handle univoco e viene scelto il seguente schema di indirizzamento:

x = "{cluster\_name}-{configuration}-{instance\_type}-{index}"

Ad esempio:

alpha-basic-ev-1

Nel dichiarazione di cui sopra, la parola “base” si riferisce a una configurazione, in cui ci sono quattro veicoli elettrici e un esploratore di blocchi. La parola “alpha” è il nome dellesperimento.

Lo Stack

Avremmo potuto scegliere Kubernetes.

Tuttavia, vogliamo anche investire in creando strumenti che la nostra comunità possa utilizzare per lanciare i propri veicoli elettrici. Scegliamo Ansible per la sua semplicità e i playbook che prendono di mira CentOS funzioneranno su qualsiasi architettura o possono essere facilmente adattati.

Inoltre, mentre ho valutato sia Chef che Puppet in passato, io ” li ho abbandonati entrambi per la semplicità di Ansible. Chef e Puppet necessitano di componenti software sulla macchina di destinazione, tuttavia, Ansible necessita solo di una connessione SSH.

Non cè fisica quantistica qui rispetto allo stack; solo passi necessari verso il successo. Il nostro stack è composto da:

  • Utenti AWS e API AWS
  • Modello di lancio AWS
  • Tag AWS
  • Avvio bash minimalista script
  • Curling di uno script bash da Github
  • Configura le variabili host Ansible dai tag
  • Fornisci lhost utilizzando Ansible

API AWS e utenti AWS

AWS offre un controllo estremamente granulare sui servizi IT tramite la sua API e gli utenti autorizzati. LAPI può essere decentemente accessibile tramite la libreria Python boto3. Un precursore dellutilizzo dellAPI è la creazione dellUtente pertinente tramite linterfaccia IAM. Un utente è un tipico ID di accesso utente e coppia segreta.

Un utente può essere associato a uno o più criteri. Un criterio è costituito da un insieme di azioni consentite o negate su un insieme di risorse.

Il nostro utente spawn ha una policy allegata con azioni minimaliste per creare listanza EC2 e azioni per leggere lintero set di risorse.

Launch Templates

Una delle funzionalità chiave che AWS ci offre sono i modelli di lancio.

Con un modello di lancio, è possibile specificare unAMI di base (lidentificatore per limmagine della macchina virtuale da cui creare unistanza) e preconfigurare impostazioni, inclusi due componenti essenziali: Tag e Esegui script. Inoltre, è possibile specificare il gruppo di sicurezza a cui dovrebbe appartenere la macchina.

I modelli di avvio possono essere dotati di versione e le istanze possono essere avviate dallutente AWS.

Tags

Ogni istanza EC2 è unica in base ai tag con cui è configurata. Le seguenti informazioni vengono inviate al nodo:

  • Nome (identificatore univoco del nodo)
  • Classe (il tipo di istanza)
  • Indice ( la posizione dellistanza)
  • Configurazione (la varietà di cluster di cui istanziare)
  • SHA (un Git SHA)
  • RegistrationIP (lindirizzo IP del Torre di registrazione)

Ognuno di questi tag è impostato nelle variabili host di Ansible.

Bootstrap con Bash

Lo script bootstrap di Bash prepara lhost per il provisioning. Alcuni dei lavori che vengono eseguiti sono linstallazione di un ambiente Python di base, lanalisi dei tag AWS, la loro scrittura nel file vars dellhost Ansible e la selezione del playbook Ansible appropriato per il tipo di nodo.

Ansible

Infine, il nodo viene fornito con Ansible. Non divagherò su Ansible poiché ci sono abbastanza altre risorse su Internet. Non cè niente di speciale qui, tranne che tipicamente si configura un server remoto con Ansible, ma nel nostro caso stiamo configurando il server locale.

Torre di registrazione

Usiamo una torre di registrazione invece di un Bootnode per avviare la rete. I veicoli elettrici registrano i loro indirizzi IP al momento dellistanza con il nodo di registrazione e un elenco di nodi statici viene ottenuto prima dellattivazione del servizio.

Il vantaggio di utilizzare una torre di questo tipo è che possiamo iniziare a registrare dati arbitrari, come le statistiche sulla salute, aiutando a chiudere il ciclo di valutazione.

Quando viene creata unistanza di un EV, scrive nellAPI di registrazione, il nome del cluster, lindirizzo IP, lindice e il tipo di istanza.

Valutazione

Lobiettivo principale della valutazione è determinare come successo lesperimento è stato. Quali sono le condizioni di successo verranno affrontate in un altro articolo. Tuttavia, una metrica immediata da tenere docchio è il costo.

Il prezzo per unistanza t2-micro è 0,012 / ora. Il costo per eseguire 96 di questi per unora dovrebbe essere solo un dollaro. Ciò può essere confermato in Cost Explorer.

Ulteriori

Questo stack funziona magnificamente. Un singolo comando porta in modo coerente e impeccabile una Mainchain completamente connessa e di propagazione dei blocchi. Quello che mi piace di più di questa pila è che è fuoco e dimentica; Posso creare unistanza del cluster, disconnettermi da Internet e fare il giocoliere. Ci sarà una Mainchain pronta per me quando tornerò.

Questo serve come una solida base per il nostro prossimo passo. Possiamo iniziare a valutare diverse configurazioni del nostro DNA di consenso. Metteremo a punto il nostro attuale algoritmo di consenso semplice e valuteremo rispetto alla realtà brutale, nel nostro prossimo articolo intitolato “Governance distribuita della posta”.

Il codice sorgente per lo stack di provisioning EV può essere trovato qui: https://github.com/unification-com/ev-provision

Unisciti a noi su Unification Gitter: https://gitter.im/unification-com

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *