Cos’è Tendermint Core? La guida più completa di sempre

Cos’è Tendermint Core? …

Tempo di lettura: 17 min

Cosmos è uno dei progetti più promettenti in circolazione. Con persone come Jae Kwon ed Ethan Buchman nella loro squadra, ha molto potenziale. Nel suo cuore e nella sua anima si trova Tendermint Core.

Guida definitiva a Tendermint

Tendermint Core combina l’algoritmo di consenso Tendermint con un protocollo di gossip p2p. Quindi, quando metti tutto insieme nello stack software, ottieni Tendermint Core insieme al livello dell’applicazione Cosmos-SDK.

Ad ogni modo, quindi prima di andare avanti, diamo un’occhiata al motivo per cui Tendermint è una tale necessità.

Bitcoin e Blockchain

Quando Satoshi Nakamoto ha creato Bitcoin, ha realizzato il primo sistema crittografico decentralizzato. La parte davvero notevole di questa scoperta è stata che è stato in grado di risolvere il problema del generale bizantino che ha aiutato una rete geografica (WAN) a raggiungere un consenso in un ambiente senza fiducia. Bitcoin ha utilizzato l’algoritmo proof-of-work per prendersi cura del loro consenso.

Detto questo, il contributo principale di Bitcoin potrebbe benissimo essere il fatto che ha introdotto il mondo intero alla tecnologia blockchain.

Una blockchain è, in termini più semplici, una serie di record immutabili di dati con data e ora gestita da un cluster di computer non di proprietà di una singola entità. Ciascuno di questi blocchi di dati (cioè blocco) è protetto e vincolato l’uno all’altro utilizzando principi crittografici (cioè catena).

In altre parole, una blockchain è un file stato deterministico macchina replicata su nodi che non si fidano necessariamente l’uno dell’altro.

Per deterministico si intende che se vengono eseguiti gli stessi passaggi specifici, si otterrà sempre lo stesso risultato.

Per esempio. 1 + 2 sarà sempre 3.

Allora, cosa significa stato? Diamo un’occhiata a Bitcoin ed Ethereum.

In Bitcoin, lo stato è un elenco di saldi per ogni account, che è un elenco di Unspent Transaction Output (UTXO). Questo stato viene modificato tramite transazioni che modificano il saldo.

D’altra parte, in Ethereum, l’applicazione è una macchina virtuale che esegue contratti intelligenti. Ogni transazione passa attraverso la Ethereum Virtual Machine e ne modifica lo stato in base allo specifico smart contract che viene chiamato al suo interno.

Se guardi l’architettura della tecnologia blockchain, vedrai tre livelli specifici:

  • Rete: La propagazione della transazione / informazione attraverso i nodi
  • Consenso: Consente ai nodi di prendere una decisione fornita >2/3 dei nodi non sono dannosi
  • Applicazione: Responsabile dell’aggiornamento dello stato dato un insieme di transazioni, ad es. L’elaborazione delle transazioni. Data una transazione e uno stato, l’applicazione restituirà un nuovo stato.

Per segnali visivi:

Guida definitiva a Tendermint

Problemi con l’attuale architettura Blockchain

Si scopre che costruire una blockchain da zero con tutti questi 3 livelli è davvero un duro lavoro. Quindi, molti progetti hanno preferito continuare con il fork del codice di base Bitcoin. Ora, anche se questo fa risparmiare un sacco di tempo, il fatto è che sono ancora ammanettati dai limiti del protocollo Bitcoin. Ovviamente, non è possibile eseguire progetti complessi quando si utilizza un protocollo noto per i suoi problemi di velocità effettiva.

Le cose sono andate molto meglio quando Ethereum è entrato in gioco. Ethereum ha effettivamente fornito agli sviluppatori una piattaforma che potevano utilizzare per creare il proprio codice personalizzato, ovvero contratti e progetti intelligenti. Tuttavia, come con Bitcoin, anche Ethereum soffre dello stesso problema. Entrambi hanno un’architettura monolitica rispetto a quella modulare.

Architettura monolitica vs architettura modulare

L’architettura monolitica significa che tutto è composto tutto in un unico pezzo. Quando il software è considerato “monolitico” i componenti sono interconnessi e interdipendenti tra loro e il design è più autonomo. In questo caso, l’architettura è più strettamente accoppiata e i componenti associati devono essere tutti presenti affinché il codice possa essere eseguito o compilato.

Anche se questo rende il sistema per cui è stato creato più robusto, non puoi davvero derivarne e creare codici personalizzati. Non è il più flessibile dei sistemi. Inoltre, c’è un altro problema con questo sistema. Se qualsiasi componente del programma deve essere aggiornato, l’intera applicazione dovrà essere rielaborata. Questa non è proprio la situazione più ideale adesso, vero??

D’altra parte, abbiamo un’architettura modulare. A differenza di Monolithic, gli strati non sono così collegati tra loro. Quindi, anche se potrebbe non essere così robusto, è abbastanza facile aggiornare l’intera applicazione lavorando con i diversi moduli separati.

Poiché i moduli sono così indipendenti, l’architettura modulare consente di aggiornare effettivamente una particolare sezione senza causare modifiche impreviste al resto del sistema. I processi iterativi sono anche molto più semplici nei programmi modulari, rispetto a quelli monolitici.

Architettura e obiettivi di Tendermint

Tendermint utilizza l’architettura modulare. I loro obiettivi sono i seguenti:

  • Fornire i livelli di rete e consenso di una blockchain come piattaforma in cui è possibile creare diverse applicazioni decentralizzate
  • Gli sviluppatori devono solo preoccuparsi del livello applicativo della blockchain, risparmiando tutte le ore che avrebbero sprecato lavorando sul consenso e anche sul livello di rete.
  • Tendermint include anche il protocollo di consenso Tendermint che è l’algoritmo di consenso bizantino tollerante ai guasti utilizzato all’interno del motore di Tendermint Core

Diamo un’occhiata a come apparirà l’architettura di Tendermint:

Guida definitiva a Tendermint

Come puoi vedere, l’applicazione è collegata a Tendermint Core tramite un protocollo socket chiamato APCI o Application Blockchain Interface. Poiché Tendermint Core e l’applicazione in esecuzione su di esso vengono eseguiti in processi UNIX separati, devono disporre di un metodo per parlare tra loro. ABCI aiuta questi due nella loro comunicazione.

Allora, qual è il design di ABCI? ABCI ne avrà alcuni componenti di design distinti:

# 1 Message Protocol

  • Coppie di messaggi di richiesta e di risposta
  • Le richieste vengono fatte dal consenso mentre l’applicazione si occupa della risposta
  • È definito utilizzando protobuf

# 2 Server / Client

  • Il motore di consenso esegue il client
  • L’applicazione esegue il server
  • Esistono due implementazioni corrette: byte grezzi asincroni e grpc

# 3 Protocollo Blockchain

ABCI è molto orientato alla connessione. Le tre connessioni per Tendermint Core sono le seguenti:

  • Connessione Mempool: controlla se le transazioni devono essere inoltrate prima che vengano confermate. Può utilizzare solo CheckTx
  • Consensus connection: questa connessione aiuta nell’esecuzione delle transazioni che sono state salvate. La sequenza dei messaggi è, per ogni blocco, BeginBlock, [DeliverTx,…], EndBlock, Commit
  • Query Connection: aiuta a interrogare lo stato dell’applicazione. Questa parte utilizza solo query e informazioni

Tutto sommato, l’obiettivo principale di Tendermint è fornire agli sviluppatori uno strumento che non sia solo pratico ma che abbia anche un alto rendimento. Ecco le proprietà di Tendermint che lo rendono così affascinante:

Compatibile con Blockchain pubblica o privata n. 1

Progetti diversi hanno esigenze diverse. Alcuni progetti devono avere un sistema aperto in cui chiunque possa partecipare e contribuire, come Ethereum. D’altra parte, abbiamo organizzazioni come l’industria medica, che non possono esporre i propri dati praticamente a tutti. Per loro, richiedono qualcosa come la blockchain autorizzata.

Ok, allora come può Tendermint aiutare a soddisfare entrambe queste esigenze? Ricorda che Tendermint gestisce solo il networking e il consenso per la blockchain. Quindi, aiuta nel:

  • Propagazione della transazione tra i nodi tramite il protocollo gossip
  • Aiuta i validatori a concordare il set di transazioni che viene aggiunto alla blockchain.

Ciò significa che il livello dell’applicazione può essere definito liberamente in qualsiasi modo gli sviluppatori desiderino che venga definito. Spetta agli sviluppatori definire come viene definito il set di validatori all’interno dell’ecosistema.

  • Gli sviluppatori possono consentire all’applicazione di avere un sistema di elezione che elegge i validatori in base al numero di token nativi che questi validatori hanno puntato all’interno dell’ecosistema..aka Proof of stake e creare una blockchain pubblica
  • Inoltre, gli sviluppatori possono anche creare un’applicazione che definisce un set limitato di validatori pre-approvati che si prendono cura del consenso e dei nuovi nodi che entrano nell’ecosistema. Questa è chiamata prova di autorità ed è il segno distintivo di una blockchain autorizzata o privata.

# 2 Alte prestazioni

Le applicazioni effettuate tramite Tendermint Core possono aspettarsi prestazioni eccezionali. Tendermint Core ha un tempo di blocco di appena 1 secondo. Può anche gestire un volume di transazioni di 10.000 transazioni al secondo per transazioni da 250 byte, a condizione che l’applicazione lo consenta.

# 3 Finalità

Qual è la finalità?

In termini semplici, significa che una volta che una certa azione è stata eseguita, non può essere ritirata. Quindi, prendiamo l’esempio di una semplice transazione finanziaria. Supponiamo che tu acquisti alcune azioni in una società, solo perché un problema tecnico nel loro sistema, non dovresti perdere la proprietà delle tue azioni. Come puoi immaginare, la finalità è estremamente critica per un sistema finanziario. Immagina di fare una transazione da un milione di dollari e poi il giorno successivo, quella transazione non è più valida a causa di un problema tecnico.

Come abbiamo accennato in precedenza, Bitcoin ed Ethereum (fino alla completa implementazione di Casper FFG) non hanno realmente una finalità di regolamento. In occasione di un hardfork o di un attacco del 51%, le transazioni hanno la possibilità di essere annullate.

Tendermint, d’altra parte, fornisce una finalità immediata entro 1 secondo dal completamento della transazione. I fork non vengono mai creati nel sistema, a condizione che meno di 2/3 dei validatori siano dannosi. Non appena viene creato un blocco (che è entro un secondo) gli utenti possono essere certi che la loro transazione è finalizzata.

# 4 Sicurezza

Tendermint è sicuro e obbliga i suoi partecipanti a essere responsabili anche delle loro azioni. Come abbiamo detto prima, tendermint non può mai essere biforcato fintanto che meno di 2/3 dei validatori sono dannosi. Se in alcuni casi la blockchain esegue il fork, c’è un modo per determinare la responsabilità. Inoltre, il consenso di Tendermint non è solo tollerante ai guasti, ma è ottimamente tollerante ai guasti bizantina

# 5 Facile da usare

Un’altra cosa grandiosa di Tendermint è la sua facilità d’uso. Come abbiamo accennato prima, hanno un’architettura modulare in cui il livello dell’applicazione può essere adeguatamente personalizzato. Ciò consente di collegare facilmente le basi di codice blockchain esistenti a Tendermint tramite ABCIs. L’esempio perfetto di questo è Etheremint che è fondamentalmente il plug di base del codice della macchina virtuale Ethereum sopra Tendermint.

Ethermint funziona esattamente come Ethereum ma beneficia anche di tutte le caratteristiche positive che abbiamo elencato sopra. Tutti gli strumenti di Ethereum come Metamask e Truffle sono compatibili con Ethermint.

# 6 Scalabilità

L’implementazione del proof-of-stake di Tendermint è molto più scalabile di un tradizionale algoritmo di consenso proof-of-work. Il motivo principale è che i sistemi basati su POW non possono eseguire lo sharding.

Lo sharding fondamentalmente partiziona orizzontalmente un database e crea database o frammenti più piccoli che vengono poi eseguiti parallelamente dai nodi. Il motivo è che un forte pool minerario può facilmente prendere il controllo di un frammento.

Tendermint consentirà l’implementazione dello sharding che aumenterà notevolmente la scalabilità.

Tendermint Consensus Protocol

Ok, quindi vediamo come funziona il protocollo di consenso Tendermint. Che cos’è esattamente un protocollo di consenso?

Ecco come Wikipedia definisce il processo decisionale basato sul consenso:

“Il processo decisionale basato sul consenso è un processo decisionale di gruppo in cui i membri del gruppo si sviluppano e accettano di sostenere una decisione nel migliore interesse del gruppo. Il consenso può essere definito professionalmente come una risoluzione accettabile, che può essere supportata, anche se non la “preferita” di ogni individuo. “Consenso” è definito da Merriam-Webster come, primo, accordo generale e, secondo, solidarietà di gruppo di convinzioni o sentimenti. “

In termini più semplici, il consenso è un modo dinamico per raggiungere un accordo in un gruppo. Mentre il voto si limita a stabilire una regola di maggioranza senza alcun pensiero per i sentimenti e il benessere della minoranza, un consenso, d’altra parte, fa sì che si raggiunga un accordo che potrebbe avvantaggiare l’intero gruppo nel suo insieme.

Da un punto di vista più idealistico, Consensus può essere utilizzato da un gruppo di persone sparse per il mondo per creare una società più equa ed equa.

Un metodo attraverso il quale si ottiene il consenso decisionale è chiamato “meccanismo di consenso”.

Quindi ora quello che abbiamo definito cos’è un consenso, diamo un’occhiata a quali sono gli obiettivi di un meccanismo di consenso (dati presi da Wikipedia).

  • Ricerca di un accordo: Un meccanismo di consenso dovrebbe portare il maggior consenso possibile da parte del gruppo.
  • Collaborativo: Tutti i partecipanti dovrebbero mirare a lavorare insieme per ottenere un risultato che metta al primo posto l’interesse del gruppo.
  • Cooperativa: Tutti i partecipanti non dovrebbero mettere al primo posto i propri interessi e lavorare come una squadra più che come individui.
  • Partecipativo: Il meccanismo di consenso dovrebbe essere tale che tutti dovrebbero partecipare attivamente al processo complessivo.
  • Inclusivo: Il maggior numero di persone possibile dovrebbe essere coinvolto nel processo di consenso. Non dovrebbe essere come un normale voto in cui le persone non hanno voglia di votare perché credono che il loro voto non avrà alcun peso a lungo termine.
  • Egualitario: Un gruppo che cerca di raggiungere il consenso dovrebbe essere il più egualitario possibile. Che cosa significa in pratica che ogni voto ha lo stesso peso. Il voto di una persona non può essere più importante di quello di un’altra.

Ora che abbiamo definito cosa sono i meccanismi di consenso ea cosa dovrebbero mirare, dobbiamo pensare all’altro elefante nella stanza.

Quali meccanismi di consenso dovrebbero essere utilizzati per un’entità come blockchain.

Prima di Bitcoin, c’erano un sacco di iterazioni di sistemi valutari decentralizzati peer-to-peer che fallivano perché non erano in grado di rispondere al problema più grande quando si trattava di raggiungere un consenso. Questo problema è chiamato “problema dei generali bizantini”.

Problema del generale bizantino

Per poter fare qualsiasi cosa in una rete peer-to-peer, tutti i nodi dovrebbero essere in grado di raggiungere un consenso. Il fatto è però che, affinché questo sistema funzioni, pone molta enfasi sulle persone affinché agiscano nel migliore interesse della rete in generale. Tuttavia, come già sappiamo, le persone non sono veramente affidabili quando si tratta di agire in modo etico. È qui che entra in gioco il problema del generale bizantino.

Guida definitiva a Tendermint

Immagina questa situazione.

C’è un esercito che circonda un castello ben fortificato. L’unico modo per vincere è attaccare il castello insieme come un’unità. Tuttavia, stanno affrontando un grosso problema. L’esercito è lontano l’uno dall’altro e i generali non possono davvero comunicare direttamente e coordinare l’attacco e alcuni generali sono corrotti.

L’unica cosa che possono fare è inviare un messaggero dal generale al generale. Tuttavia, molte cose potrebbero accadere al messenger. I generali corrotti possono intercettare il messaggero e modificare il messaggio. Allora, cosa possono fare i generali per assicurarsi di lanciare un attacco coordinato senza fare affidamento sull’etica di ogni singolo generale? Come possono giungere a un consenso senza fiducia per fare ciò che deve essere fatto?

Questo è il problema del generale bizantino e Satoshi Nakamoto ha risolto questo problema utilizzando il meccanismo di consenso Proof-of-Work (POW).

Che cos’è la prova di lavoro?

Controlliamo come funziona POW con il contesto del nostro esempio dato sopra. Supponiamo che un generale voglia comunicare con un altro generale. Come pensi che andrà giù?

  • Un “nonce” viene aggiunto al messaggio originale. Il nonce è un valore esadecimale casuale.
  • Questo nuovo messaggio viene quindi sottoposto a hashing. Supponiamo che i generali concordino in anticipo sul fatto che invieranno solo messaggi, che quando sottoposti a hash iniziano con 4 “0”.

    Se l’hashed non fornisce il numero desiderato di 0, il nonce viene modificato e il messaggio viene nuovamente sottoposto ad hashing. Questo processo continua a ripetersi fino a quando non viene ricevuto l’hash desiderato.

  • L’intero processo richiede molto tempo e richiede molta potenza di calcolo.
  • Ora, quando finalmente ottengono il valore hash, al messaggero viene dato il messaggio originale e il nonce e gli viene detto di comunicare con gli altri generali. Quindi cosa succede se qualcuno cerca di intercettare il messaggio? Bene, ricordi l’effetto valanga delle funzioni hash? Il messaggio cambierà drasticamente e poiché non inizierà più con il numero richiesto di “0”, le persone si renderanno conto che il messaggio è stato manomesso.

Quindi, per inserire POW nel contesto del crypto mining:

  • I minatori cercano di risolvere enigmi crittografici per aggiungere un blocco alla blockchain.
  • Il processo richiede molto impegno e potenza di calcolo.
  • I minatori presentano quindi il loro blocco alla rete bitcoin.
  • La rete quindi controlla l’autenticità del blocco semplicemente controllando l’hash, se è corretto, viene aggiunto alla blockchain.

Quindi, scoprire il nonce e l’hash richiesti dovrebbe essere difficile, tuttavia controllare se sono validi o meno dovrebbe essere semplice. Questa è l’essenza della prova di lavoro.

Ora, probabilmente ti starai chiedendo, perché i minatori dovrebbero sacrificare il loro tempo e le loro risorse per estrarre bitcoin? Bene, si scopre che hanno un incentivo economico abbastanza salutare:

Quando scopri un blocco, ricevi una ricompensa per blocco di 12,5 bitcoin. La ricompensa si dimezza ogni 210.000 blocchi.

Dopo aver estratto un blocco, diventi il ​​dittatore temporaneo del blocco. Sei il responsabile dell’inserimento delle transazioni all’interno del blocco e quindi hai diritto alle commissioni di transazione.

C’è solo un numero limitato di bitcoin là fuori, 21 milioni per la precisione. Quindi, cosa impedisce a questi minatori di estrarre tutti i bitcoin contemporaneamente?

Si scopre che l’estrazione di bitcoin diventa progressivamente più difficile nel tempo. Questa funzione è chiamata “difficoltà” e la difficoltà del mining continua ad aumentare man mano che si continua a estrarre.

Questo è il motivo per cui oggigiorno è praticamente impossibile per i miner da soli estrarre Bitcoin usando solo i loro computer. I minatori hanno ora unito le forze e creato “pool minerari” per mettere insieme la loro potenza di calcolo e fare miniere come gruppo. Questi pool utilizzano ASIC (Application-Specific Integrated Circuits) creati appositamente per il mining di bitcoin.

Problemi con POW

Ci sono tre problemi principali con gli algoritmi Proof of Work. Ne abbiamo già parlato in dettaglio in precedenza, quindi faremo solo una panoramica generale.

  • Spreco di energia: Bitcoin consuma più energia dell’Irlanda e della Repubblica slovacca. Questo enorme spreco di energia è uno dei principi di Bitcoin. È spreco per amore dello spreco.
  • Centralizzazione: Come ti abbiamo già detto, Bitcoin utilizza gli ASIC per il mining. Il problema è che gli ASIC sono costosi e le piscine con più soldi tendono ad avere più ASIC e, di conseguenza, più potenza di mining. In quanto tale, Bitcoin non è decentralizzato come vorrebbe essere.
  • Scalabilità: La stessa architettura di POW impedisce la scalabilità. Bitcoin gestisce solo 7 transazioni al secondo. Per un sistema finanziario moderno, semplicemente non è abbastanza adeguato.

Entra Tendermint

Quindi, per contrastare i molti problemi con il sistema di consenso Proof-of-Work, Jae Kwon, un laureato in informatica e ingegneria dei sistemi, ha creato Tendermint. Tendermint è un protocollo basato esclusivamente su BFT, costruito in un ambiente senza autorizzazione con il Proof-of-Stake (PoS) come meccanismo di sicurezza sottostante.

A causa della complessità, Tendermint ha impiegato quasi 4 anni per essere completato.

Jae Kwon e il CTO di Tendermint Ethan Buchman si sono ispirati a Raft e PBFT per creare un sistema di consenso che soddisfacesse il problema del generale bizantino. È

“Modellato come un protocollo deterministico, vive in una sincronia parziale, che raggiunge il throughput entro i limiti della latenza della rete e dei singoli processi stessi.”

Va bene, sappiamo che sono molte parole complicate da lanciare una dopo l’altra, ma per capire cos’è il consenso di Tendermint e perché è stato progettato nel modo in cui è stato progettato, è necessario capire cosa significano alcuni di questi termini complicati. Vedrai come tutti si collegano tra loro come un intricato puzzle.

Impossibilità FLP n. 1

L’impossibilità FLP (Fischer Lynch Paterson) afferma che un algoritmo di consenso può avere solo 2 delle 3 proprietà seguenti:

  • Sicurezza
  • Risoluzione o vivacità garantite
  • Tolleranza agli errori

Guida definitiva a Tendermint

Credito immagine: medio

In altre parole, l’impossibilità FLP stati quello

“Sia la risoluzione che l’accordo (vivacità e sicurezza) non possono essere soddisfatti in modo vincolato nel tempo in un sistema distribuito asincrono, se deve essere resiliente ad almeno un guasto (dimostrano il loro risultato per la tolleranza ai guasti generale, che è più debole del difetto bizantino tolleranza, poiché richiede solo un nodo fail-stop, quindi BFT è incluso nelle dichiarazioni di impossibilità FLP). “

Quindi, fondamentalmente, è del tutto impossibile per una WAN asincrona giungere a un consenso poiché non esiste una quantità specifica di tempo che i nodi impiegheranno per ricevere, elaborare e rispondere ai messaggi. Questo è ovviamente un grosso problema perché è estremamente poco pratico per una grande rete di nodi come Bitcoin presumere che si sincronizzeranno.

Ok, quindi la sincronicità sarebbe stata un problema. Tuttavia, i ricercatori Dwork, Lynch e Stockmeyers hanno lanciato un’ancora di salvezza qui con il loro articolo chiamato “Consenso in presenza di sincronia parziale.”Questo è stato chiamato consenso DLS.

# 2 Consenso DLS e sincronizzazione parziale

Il documento DLS afferma che tra un sistema sincrono e un sistema asincrono, esiste un sistema speciale che è “parzialmente sincrono”. Poiché questo sistema parzialmente sincrono può avere un tempo limite superiore dato, sarà in grado di progettare un protocollo BFT fattibile.

Secondo DLS, la vera sfida nella progettazione di protocolli è averne uno che funzioni correttamente in un sistema parzialmente sincrono.

Quindi, vediamo come funzionano i protocolli decentralizzati popolari come Bitcoin ed Ethereum a tale riguardo.

Bitcoin ha un limite superiore noto che è di circa 10 minuti. Quindi, viene prodotto un blocco di transazioni ogni 10 minuti. Questa ipotesi di temporizzazione è imposta alla rete in modo che i nodi abbiano 10 minuti interi per raccogliere le informazioni e trasmetterle tramite gossip.

Cos'è la macchina a stati?

D’altra parte, abbiamo Ethereum che fa ipotesi di sincronia per i loro blocchi e la rete mantenendo un tempo di blocco superiore su 15 secondi. Con un tempo di blocco così basso, sono più scalabili di Bitcoin, tuttavia non sono così efficienti. I minatori di Ethereum producono molti blocchi orfani.

# 3 Vita e risoluzione

La risoluzione è una proprietà che afferma che ogni processore corretto dovrebbe eventualmente prendere una decisione. La maggior parte degli algoritmi di consenso che abbiamo in questo momento si basano su modelli sincroni per la loro sicurezza e terminazione. Hanno limiti fissi e regole note quindi, nel caso in cui non reggano, la catena si biforca in più protocolli

Certo ci sono protocolli di consenso che funzionano in reti asincrone, tuttavia, seguendo il teorema di impossibilità FLP, non possono essere deterministici. Il che ci porta a ….

# 4 Protocolli deterministici e non deterministici

Di solito, i protocolli di consenso puramente asincroni dipendono da membri non deterministici come Oracles, il che comporta un alto grado di incertezza e complessità.

Allora come si comporta Tendermint con tutti questi fattori?

Tendermint è un consenso BFT per lo più asincrono, deterministico, in cui i validatori hanno una posta in gioco che denota il loro potere di voto. Nel triangolo dell’impossibilità FLP, preferisce la tolleranza agli errori e la sicurezza (coerenza) rispetto alla vivacità.

Tendermint oscilla costantemente tra periodi di sincronia e asincronia. Ciò significa che, sebbene si basi su ipotesi temporali per fare progressi, la velocità di tale progresso non dipende dai parametri di sistema ma dipende invece dalla velocità reale della rete.

Inoltre, Tendermint non esegue mai il fork in presenza di asincronia se meno di 1/3 dei validatori sono corrotti / incuranti. Questo è il vero motivo per cui Tendermint è Byzantine Fault Tolerant. Come abbiamo detto prima, Tendermint si concentra sulla sicurezza al di sopra della vivacità. Quindi, se più di un terzo dei validatori è dannoso, invece del fork della rete, la blockchain di Tendermint si fermerà temporaneamente fino a quando più 2/3 validatori non raggiungeranno un consenso.

Tendermint è anche completamente deterministico e non c’è casualità nel protocollo. I leader del sistema sono tutti eletti in una versione deterministica, tramite una funzione matematica definita. Quindi, possiamo effettivamente dimostrare matematicamente che il sistema si sta comportando nel modo in cui dovrebbe comportarsi.

Tendermint – Il sistema Proof of Stake

In un sistema di proof of stake (POS), abbiamo alcune persone chiamate “validatori”. Questi validatori bloccano una posta all’interno del sistema. Dopodiché, hanno la responsabilità di scommettere sul blocco che ritengono verrà aggiunto accanto alla blockchain. Quando il blocco viene aggiunto, ricevono una ricompensa proporzionale alla loro puntata.

Bene, ecco come funziona un POS generico. Ora, vediamo come funziona la tendermint.

Per prima cosa familiarizziamo con alcuni dei termini che utilizzeremo:

  • Una rete è composta da molti nodi. I nodi che sono collegati a un particolare nodo sono chiamati peer.
  • Il processo di consenso si svolge a una particolare altezza del blocco H. Il processo per determinare il blocco successivo consiste in più round.
  • Il round è composto da molti stati che sono: NewHeight, Propose, Prevote, Precommit e Commit. Ogni stato è chiamato Roundstep o semplicemente “step”.
  • Si dice che un nodo si trovi a una determinata altezza, rotondo e gradino, o in (H, R, S) o in (H, R) in breve per omettere il gradino.
  • Prevenire o preimpegnare qualcosa significa trasmettere un voto precedente o un voto anticipato per qualcosa.
  • Quando arriva un blocco >2/3 dei precedenti in (H, R) quindi è chiamato proof-of-lock-change o PoLC.

Qual è la macchina a stati?

La macchina a stati è il motore del protocollo Tendermint per così dire. Il diagramma seguente ti dà una buona idea di come sarà:

Cos'è la macchina a stati?

Ok, allora cosa sta succedendo qui?

Ricordi gli stati che attraversa ogni round? NewHeight, Propose, Prevote, Precommit e Commit.

Di questi, “Propose, Prevote, Precommit” consistono in un round mentre gli altri due sono round speciali. In uno scenario ideale, la transizione di stato si comporterebbe in questo modo:

NewHeight -> (Proporre -> Prevote -> Precommit)+ -> Commettere -> NewHeight ->…

Tuttavia, non è così che potrebbe funzionare sempre. Possono essere necessari più round prima che il blocco venga commesso. I seguenti sono i motivi per cui potrebbero essere necessari più round:

  • Il proponente designato può essere assente.
  • Il blocco proposto potrebbe non essere valido.
  • Il blocco non si è propagato nel tempo.
  • >2/3 delle anteprime non sono state ricevute in tempo dai nodi del validatore.
  • Anche se è necessario un +2/3 di prevote per passare al passaggio successivo, almeno un validatore potrebbe aver votato o votato con cattiveria.
  • >2/3 dei precommit per il blocco non sono stati ricevuti anche se è possibile che siano stati ricevuti preventivi.

Cosa succede durante ogni stato?

Va bene … quindi ora esaminiamo ogni stato e vediamo come l’intera faccenda si riunisce.

Proporre

In questa fase, il proponente designato, ovvero il nodo selezionato propone un blocco da aggiungere in (H, R). Questa fase termina in due modi:

Il blocco viene proposto e questo entra nella fase precedente.

Scade il tempo del proponente per scegliere il blocco in cui comunque entra nella fase precedente.

Prevote

Ora veniamo alla fase precedente. In questa fase, ogni validatore deve prendere una decisione.

  • Se in qualche modo, il validatore è bloccato su un blocco proposto da un round precedente, si disconnette automaticamente e trasmette quel blocco.
  • Se il validatore ha ricevuto una proposta accettabile per il round in corso, allora firma e trasmette un prevote per il blocco proposto.
  • Tuttavia, se trovano qualcosa di strano nella proposta o non hanno ricevuto alcuna proposta (ad es. Se il tempo del proponente scade), allora firmano con un “zero” prevote.
  • Non si verifica alcun blocco del blocco durante questa fase.
  • Durante questo periodo, tutti i nodi propagano le prevote in tutto il sistema tramite il protocollo gossip.

Precommit

Ora entriamo nella fase finale del “round” chiamato “precommit”. Entrando in questa fase, i validatori si impegnano in anticipo alla loro decisione trasmettendo le loro anticipazioni. Può verificarsi uno dei tre scenari seguenti:

  • Se il validatore riceve >2/3 dei prevotes per un particolare blocco accettabile quindi il validatore si disconnette e trasmette il loro precommit al blocco. Si bloccano anche su quel blocco. Un validatore può bloccare solo un blocco alla volta.
  • Tuttavia, se il validatore riceve più di 2/3 della prevendita NUL, si sblocca e il preimpegno passa a “NIL”.
  • Infine, se non hanno ricevuto una maggioranza assoluta di 2/3, non si disconnettono o non bloccano nulla.

Durante questa fase, i nodi continuano a spettegolare continuamente sui precommit in tutta la rete.

Alla fine, se il blocco proposto ottiene più di 2/3 dei precommit, ci spostiamo verso il passaggio “Commit”. Tuttavia, se non raggiungono quella fase, entrano nella fase “Proponi” del round successivo.

Commettere

Lo stato Commit non fa parte del “round”. Insieme a NewHeight, è uno dei due round speciali. Durante lo stato di commit, vengono verificate due condizioni parallele per vedere se vengono soddisfatte o meno.

  • In primo luogo, i validatori devono ricevere il blocco che è stato precommesso dalla rete. Una volta fatto, firmano e trasmettono il loro impegno.
  • In secondo luogo, devono attendere fino a quando non hanno ricevuto almeno 2/3 dei preimpegni per il blocco.

    Fatto ciò, il blocco viene impegnato nella rete.

NewHeight

Aumenta semplicemente l’altezza del blocco di 1 per mostrare che il blocco è stato aggiunto.

Scegliere i validatori

Come avrai già capito, la scelta del set iniziale di validatori è fondamentale per il funzionamento di Cosmos. Quindi, esattamente come verranno scelti?

A differenza di Bitcoin in cui chiunque può diventare un minatore in qualsiasi momento, ci sono solo così tanti validatori che il sistema Tendermint può accettare. Poiché i validatori individualmente dovranno svolgere molte funzioni, aumentare il conteggio dei validatori porterà solo a ritardi.

Questo è il motivo per cui Cosmos ha deciso di scegliere 100 validatori durante il Genesis day (ovvero il giorno della raccolta fondi). Il numero di validatori aumenterà del 13% ogni anno fino a 10 anni quando si stabilirà su 300.

Guida definitiva a Tendermint

Allora, per quanto riguarda i risultati?

Come afferma il white paper del cosmo:

“Tendermint offre prestazioni eccezionali. Nei benchmark di 64 nodi distribuiti su 7 datacenter in 5 continenti, su istanze di commodity cloud, Tendermint consensus può elaborare migliaia di transazioni al secondo, con latenze di commit dell’ordine di uno o due secondi. In particolare, le prestazioni di oltre un migliaio di transazioni al secondo vengono mantenute anche in condizioni difficili, con validatori che si bloccano o trasmettono voti maliziosi “.

Il grafico sottostante supporta l’affermazione fatta sopra:

Casper contro Tendermint

Insieme a Tendermint, Casper è un’altra popolare implementazione del protocollo POS.

Mentre Tendermint si concentra sulla sicurezza, l’attenzione di Casper è sulla vivacità, rispetto all’impossibilità di FLP. Allora, cosa succede a Casper durante un fork?

Casper FFG consentirà a una blockchain di continuare a essere costruita, pur avendo la proprietà che tutti i nodi saranno consapevoli che questa catena non è finalizzata. Quindi, la blockchain può rimanere disponibile senza alcuna finalità. I validatori della catena hanno la possibilità di passare alla catena biforcuta. Se più di 2/3 dei validatori votano, cambiano le catene.

Inoltre, Casper ha un famoso meccanismo di taglio. Qualsiasi tipo di attacco dannoso porterà i convalidatori a ridurre immediatamente la posta in gioco.

Conclusione di Tendermint

Così il gioco è fatto. Ci auguriamo di averti fornito quante più informazioni preziose possibili. Cosa ne pensate di Tendermint e delle sue potenzialità? Suona nella sezione commenti qui sotto!

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me