Blockchain

Blockchain: spiegazione tecnica del funzionamento

Questa pillola è stata creata per spiegare il processo tecnico mediante il quale un insieme di dati viene convalidato replicandolo in un sistema decentralizzato.
Può essere

  • Pubblico
  • Privato
  • Federeted(R3 + HyperLedger)
Blockchain tabella 1 ita

Come funziona un Blockchain: Rooted in algoritmi crittografici

Le blockchain usano una serie di equazioni per sbloccare porzioni di una struttura di dati, riempirla di informazioni, e contemporaneamente replicare e archiviare le informazioni in quell'oggetto di dati.
Protocolli di consenso.

  • Prova di lavoro (PoW)
  • Prova del palo (PoS)
  • Prova del tempo trascorso (Poet) e Prova del concetto (PoC)

In che modo questo differisce dagli attuali sistemi che abbiamo in atto
I sistemi correnti hanno tipicamente un nodo principale, centralizzato, la struttura che è la fonte attendibile.
In Blockchain, la fonte attendibile è il sistema distribuito stesso (creazione di un sistema "trustless"), con l'algoritmo che alimenta le chiavi pubbliche e private all'interno del sistema,

Il sistema corrente tipicamente ha un nodo principale, centralizzato e strutturato nella sorgente di fiducia. Nella Blockchain, la sorgente di fiducia è il sistema distribuito stesso (creandoparadossalmente un sistema "senza fiducia"), garantendo al pubblico e al privato di entrare a far parte del sistemadi delle chiavi private, creando così un network di dati certificati e aventi fiducia.

Transazioni transfrontaliere e P2P

Con un insieme decentralizzato e affidabile di nodi che elaborano gli oggetti dati, tutte le transazioni di dati possono essere inviate ovunque con il minimo sforzo e quindi le commissioni.
A causa delle caratteristiche valutarie attribuite alle tecnologie Blockchain, ciò significa anche che l'invio di valori valutari in tutto il mondo
Oltre a questo, uno dei principali vantaggi della tecnologia blockchain risiede nella sua velocità: può ridurre i tempi di insediamento in pochi minuti e può ridurre esponenzialmente i costi di scadenza.
Il rischio di controparte è quasi eliminato attraverso l'uso di un libro mastro distribuito decentralizzato e trasparente

Spazio legislativo e conformità

In un sistema di rete distribuito e globale che si occupa dell'elaborazione di grandi insiemi di dati (come valuta o contratti), le norme relative alle implementazioni private devono ancora essere stabilite
La conformità e i regolamenti sono a discrezione del proprietario della Blockchain

Contabilità e contabilità distribuita

I set di dati creati all'interno di Blockchain che trattano le rappresentazioni di valute vengono spesso definiti come Ledger.
Questi registri "Triple Entry" consentono una convalida distribuita dei saldi in valuta, informazioni, transazioni, mittenti e destinatari, automaticamente crittografati e attendibili.
Questo modello consente una cronologia finanziaria semplificata, trasparente, verificabile e facilmente rintracciabile.

Introduzione agli Smart Contracts

Un contratto intelligente è essenzialmente una logica aziendale in esecuzione su una blockchain. I contratti intelligenti possono essere semplici come un aggiornamento dei dati o complessi quanto l'esecuzione di un contratto con condizioni allegate. Ad esempio, un contratto intelligente può aggiornare un saldo del conto, con la convalida per assicurarsi che ci sia abbastanza denaro in un conto prima di fare un addebito. È possibile scrivere un contratto intelligente più complesso per stabilire che il costo di spedizione di un articolo dipende da quando arriva. Con i termini concordati da entrambe le parti e scritti nel libro mastro, i fondi appropriati cambiano automaticamente le mani quando l'oggetto viene ricevuto. Esistono due diversi tipi di contratti intelligenti:

• I contratti intelligenti installati installano la logica aziendale sui validatori nella rete prima dell'avvio della rete.

• I contratti intelligenti su catena implementano la logica aziendale come una transazione impegnata nella blockchain e quindi richiamata dalle transazioni successive.

Con contratti intelligenti su catena, il codice che definisce la logica aziendale diventa parte del libro mastro. 4 Quali framework Hyperledger supportano gli Smart Contracts? Quattro framework blockchain di Hyperledger supportano contratti intelligenti:

• Hyperledger Burrow

• Hyperledger Fabric

• Hyperledger Iroha

• Hyperledger Sawtooth

In tutti questi framework, il livello del contratto intelligente è responsabile dell'elaborazione delle richieste di transazione e della determinazione delle transazioni valide eseguendo la business logic. Ogni framework supporta contratti intelligenti in un modo leggermente diverso, come mostrato a pagina 8 e discusso nelle sezioni successive di questo documento. Come vengono elaborati i contratti intelligenti La Figura 1 mostra come viene elaborata una richiesta inviata a un contratto intelligente. Gli input includono l'identificativo del contratto, la richiesta di transazione, eventuali dipendenze che possono esistere e lo stato corrente del libro mastro. L'interprete del contratto, il blocco nel mezzo, viene caricato con lo stato corrente del libro mastro e il codice del contratto intelligente. Quando l'interprete del contratto riceve una richiesta, verifica immediatamente e quindi respinge tutte le richieste non valide.

blockchain grafico 1 ita

Per errori di sintassi come input non validi, firma non verificabile e qualsiasi transazione ripetuta (a causa di errori o attacchi di replay), la richiesta dovrebbe essere abbandonata.

Gli errori logici sono più complessi e la decisione di continuare l'elaborazione dovrebbe essere basata su criteri. Ad esempio, se una richiesta provocherebbe un errore di controllo della doppia spesa o del controllo della versione, potrebbe essere necessario registrare tale richiesta per il controllo, se richiesto dalla politica.

Il risultato della convalida di una richiesta in un contratto intelligente è una transazione che cattura la transizione verso il nuovo stato. Ogni framework di Hyperledger rappresenta la transizione di stato in modo diverso; ad esempio, Hyperledger Fabric utilizza i set di modifiche, mentre Hyperledger Sawtooth utilizza gli stati verificabili crittograficamente.

Questa separazione tra esecuzione del contratto e consenso complica l'impegno nei confronti della blockchain. Ad esempio, due richieste eseguite in parallelo possono provocare incoerenze nello stato del contratto, a meno che non siano ordinate in un modo specifico. In generale, lo strato di consenso gestisce l'ordinamento. Tuttavia, il contratto intelligente ha la possibilità di fornire suggerimenti su proprietà come l'ordinazione.

L'elaborazione di una richiesta può generare effetti collaterali: risultati che non vengono catturati nel delta di stato. Gli effetti collaterali possono includere notifiche di eventi, richieste ad altri contratti intelligenti, modifiche a risorse globali o anche azioni irreversibili come la distribuzione di informazioni sensibili o la spedizione di un pacchetto.

Dipendenze delle transazioni

Tutti e quattro i framework Hyperledger che supportano i contratti intelligenti - Hyperledger Burrow, Hyperledger Fabric, Hyperledger Iroha e Hyperledger Sawtooth - presuppongono che le transazioni siano atomiche. In altre parole, una transazione è considerata non ancora avviata o completata; una transazione non può essere parzialmente completata. Ciò garantisce l'integrità della transazione.

Quando le azioni dipendenti (se questo è il momento) devono essere impegnate insieme, alcuni framework presuppongono che le azioni dipendenti siano acquisite in un singolo contratto intelligente. Altri consentono il batching di transazioni su più smart contract. Pertanto, i contratti intelligenti possono specificare dipendenze tra più transazioni che devono essere eseguite in modo atomico. Questi riferimenti possono essere impliciti o espliciti.

Con un riferimento implicito, è solitamente impossibile determinare l'ordine in cui le transazioni devono essere applicate. Bitcoin risolve questo problema tentando ripetutamente di applicare la transazione, il che si traduce in una graduale esecuzione delle transazioni man mano che i loro prerequisiti sono soddisfatti.

Questo comportamento richiede un componente di gestione temporanea della transazione, ad esempio mempool, che si occupa di tutte le transazioni in scadenza che il sistema non è in grado di applicare.

Con un riferimento esplicito, l'utente che invia le transazioni specifica l'ordine con una qualche forma di identificatori di transazione.

Proprio come i riferimenti impliciti ed espliciti influenzano la formazione del blocco, così fa il grafico delle dipendenze. Il grafico delle dipendenze può essere ciclico o aciclico, in altre parole, circolare o non circolare.

Con le dipendenze cicliche, l'intero gruppo che contiene il ciclo deve essere incluso nello stesso blocco. Ad esempio se la transazione A dipende dalla transazione B e la transazione B dipende dalla transazione C e la transazione C dipende dalla transazione A, allora tutte e tre le transazioni devono essere incluse nello stesso blocco.

blockchain grafico 2 trasparente

Questa figura mostra come i contratti intelligenti si adattano agli altri livelli architettonici blockchain. Questa è una visione generalizzata, poiché i progettisti di qualsiasi framework Hyperledger possono scegliere di implementare questi passaggi in modo diverso. In generale, lo strato di contratto intelligente funziona a stretto contatto con il livello di consenso. Nello specifico, lo strato di contratto intelligente riceve una proposta dal livello di consenso1. Questa proposta specifica il contratto da eseguire, i dettagli della transazione, inclusi l'identità e le credenziali dell'entità che chiede di eseguire il contratto e tutte le dipendenze della transazione. Il livello di contratto intelligente utilizza lo stato corrente del libro mastro e l'input dal livello di consenso per convalidare la transazione. Durante l'elaborazione della transazione, il livello del contratto intelligente utilizza il livello dei servizi di identità per autenticare e autorizzare l'entità che chiede di eseguire il contratto intelligente. Ciò assicura due cose: che l'entità sia nota sulla rete blockchain e che l'entità abbia l'accesso appropriato per eseguire il contratto intelligente. L'identità può essere fornita attraverso diversi metodi: semplici identità basate su chiavi, identità e credenziali gestite attraverso il registro generale, credenziali anonime o servizi di identità gestiti da un'autorità di certificazione esterna.

Dopo l'elaborazione della transazione, il livello del contratto intelligente restituisce se la transazione è stata accettata o rifiutata. Se la transazione è stata accettata, lo strato del contratto intelligente restituisce anche un attestato di correttezza, un delta di stato e qualsiasi suggerimento di ordine facoltativo necessario per garantire che le dipendenze della transazione vengano prese in considerazione. Il delta di stato include i set di modifiche e gli eventuali effetti collaterali che dovrebbero verificarsi quando la transazione viene eseguita correttamente
i pari.

Integrità e disponibilità di Smart Contract

Per garantire l'integrità e la disponibilità della rete blockchain e del livello del contratto intelligente, le blockchain aziendali devono controllare l'accesso a determinate risorse. Poiché i contratti intelligenti sono programmi, sono vulnerabili a attacchi dannosi, errori di codifica e progettazione scadente. Una rottura in una di queste aree può compromettere l'integrità o la disponibilità del sistema blockchain.
Hyperledger consiglia le quattro salvaguardie seguenti da utilizzare con il livello del contratto intelligente per garantire l'integrità e la disponibilità.
1. Protezione da negazione del servizio
In un attacco DoS (denial-of-service) malevolo, l'autore del reato cerca di rendere una macchina o la risorsa di rete non disponibile agli utenti previsti interrompendo temporaneamente i servizi. Questo è spesso fatto sommergendo il computer, il server o la rete con una serie di richieste volte a sovraccaricare il sistema in modo che non possa servire richieste legittime.
Nelle reti di blockchain autorizzate che operano in un ambiente di fiducia parziale, gli attacchi DoS dannosi possono essere ridotti utilizzando la gestione delle identità e le politiche di controllo degli accessi. Questi aiutano a garantire che solo le entità conosciute possano partecipare alla rete blockchain. Se un cattivo attore ottiene l'accesso alla rete tramite spoofing o altre appropriazioni indebite di identità e quindi avvia un attacco DoS, la fonte può essere identificata, isolata e rimossa.
2. Sandboxing
Un sistema di blockchain progettato in modo sicuro deve garantire che i contratti intelligenti possano eseguire solo le funzioni necessarie per eseguire una determinata transazione. Senza garanzie, codice di contratto intelligente malevolo o errato potrebbe corrompere la rete, rischiando il furto o l'esposizione di privati
dati.
Una varietà di tecniche comprovate per isolare l'ambiente di esecuzione può essere applicata al livello del contratto intelligente, come partizioni e contenitori.
3. Gestione delle risorse / Controllo del flusso
Per errore o intento malevolo, un contratto smart difettoso può consumare risorse di rete eccessive, impedire l'esecuzione di altri contratti o comunque degradare il sistema. Il controllo del flusso si riferisce a tecniche come la contropressione e la protezione da sovraccarico che garantiscono la disponibilità di risorse.
I sistemi blockchain aziendali possono applicare tecniche di gestione delle risorse basate su tempo o token per garantire che un particolare contratto intelligente non consumi risorse eccessive.
4. Application Lifecycle Management (ALM)
Poiché i contratti intelligenti sono codice dell'applicazione, devono essere gestiti attraverso l'intero ciclo di vita del software, inclusi test, distribuzione, aggiornamenti e rimozione delle autorizzazioni. I sistemi blockchain aziendali devono fornire queste funzioni in modo nativo o integrandosi con gli strumenti ALM.

Contratti intelligenti nei framework di Hyperledger

Poiché le diverse aziende hanno requisiti diversi per blockchain, la comunità di Hyperledger sta lavorando su diversi modi per implementare contratti intelligenti. La Tabella 1 mette a confronto le implementazioni del contratto intelligente utilizzate nei framework Hyperledger. Per ogni framework, la tabella elenca la tecnologia del contratto intelligente utilizzata, il tipo di contratto intelligente (installato o on-chain) e le principali lingue di programmazione utilizzate per scrivere contratti intelligenti

blckchain tabella 1 en

Smart Contracti in Hyperledger Burrow

Hyperledger Burrow è una macchina a contratto intelligente autorizzata. Fornisce un client blockchain modulare con un interprete di contratto intelligente autorizzato costruito secondo le specifiche della Ethereum Virtual Machine (EVM), con alcune estensioni e alcuni cambiamenti ancora da incorporare. Hyperledger Burrow accoppia il suo motore di esecuzione EVM con il motore di consenso di Tendermint su un'interfaccia di consenso alle applicazioni chiamata ABCI. Lo stato dell'applicazione è costituito da tutti gli account, il set di validatori e il registro dei nomi. Gli account in Hyperledger Burrow dispongono di autorizzazioni e contengono codice del contratto intelligente o corrispondono a una coppia di chiavi pubblica-privata. Una transazione che richiede il codice del contratto intelligente in un determinato account attiverà l'esecuzione del codice di quell'account in una macchina virtuale autorizzata.
Il motore di applicazione del contratto intelligente fornisce gran parte del valore di Hyperledger Burrow. Questo motore fornisce le interfacce necessarie per essere utilizzato come libreria. Alcuni dei suoi sottocomponenti chiave sono descritti di seguito. Stato globale dell'applicazione Lo stato dell'applicazione è costituito da tutti gli account, il set di validatori e il registro dei nomi incorporato di Hyperledger Burrow. Una transazione che richiede il codice del contratto intelligente in un determinato account attiverà l'esecuzione del codice di quell'account in una macchina virtuale autorizzata. Funzioni native sicure Le funzioni native sicure forniscono le regole di base che devono seguire tutti gli account e tutto il codice di contratto intelligente. Non risiedono come codice EVM, ma sono esposti all'EVM autorizzato tramite contratti di interfaccia. L'autorizzazione viene applicata tramite funzioni native sicure. E l'autorizzazione è alla base dell'esecuzione di tutto il codice di contratto intelligente.

Hyperledger Burrow prevede un framework di funzioni native sicure che supporta l'uso del codice della lingua nativa per prestazioni e sicurezza più elevate. Le funzioni native sicure possono essere esposte all'EVM autorizzato all'interno di Hyperledger Burrow.

Le funzioni native sicure possono anche essere strutturate per supportare le migliori prestazioni dei contratti intelligenti. Le funzioni native sicure possono fornire una gamma di funzioni a livello privilegiato alle applicazioni ecosistemiche che dovrebbero essere costruite in modo nativo ed esposte all'event EVM autorizzato. Gli sforzi sono in corso per sistematizzare questo e aggiungere funzionalità avanzate per supportare un'ampia varietà di utenti.

Livello di autorizzazione

Hyperledger Burrow viene fornito con un livello di autorizzazione basato sulle funzionalità e evolutivo.

La rete viene avviata con un set iniziale di account con autorizzazioni più un set predefinito globale di autorizzazioni. I partecipanti alla rete con l'autorizzazione corretta possono modificare le autorizzazioni di altri account inviando un tipo di transazione appropriato alla rete. Questa transazione viene controllata dai validatori di rete prima che le autorizzazioni vengano aggiornate sull'account di destinazione. Attraverso l'EVM, ulteriori autorizzazioni sofisticate basate sui ruoli possono essere sfruttate tramite i ruoli di Hyperledger Burrow su ciascun account. I ruoli possono essere aggiornati tramite transazioni discrete o contratti intelligenti.

Inoltre, Hyperledger Burrow espone la possibilità di contratti intelligenti all'interno del EVM autorizzato per modificare il livello di autorizzazione e i ruoli dell'account. Una volta che un contratto con questa funzionalità è stato implementato in una catena, un partecipante alla rete con le autorizzazioni appropriate può concedere al contratto tale capacità.

EVM autorizzato

Questa macchina virtuale è costruita per osservare le specifiche del codice di operazione di Ethereum e asserire che sono state concesse le autorizzazioni corrette. Una quantità arbitraria ma finita di gas, la commissione di esecuzione per ogni operazione eseguita su Ethereum, viene distribuita per ogni esecuzione. Ciò garantisce che l'esecuzione sarà completata entro un certo periodo di tempo.

Le transazioni devono essere formulate in un formato binario che può essere elaborato dal nodo blockchain utilizzando una Application Binary Interface (ABI). Una serie di strumenti open source di Monax e della comunità Ethereum consentono agli utenti di compilare, distribuire e collegare contratti intelligenti compilati per l'EVM autorizzato e formulare transazioni che chiamano contratti intelligenti.

Lo stesso EVM autorizzato è progettato e implementato come una funzione stateless per la transizione in modo deterministico e verificabile dello stato EVM in base a una transazione. Questo pacchetto di codice potrebbe essere integrato in diversi progetti Hyperledger. Ad esempio, le famiglie di transazioni estensibili in Sawtooth di Hyperledger ci consentono di pensare all'EVM autorizzato come processore di transazione nel framework del libro mastro autorizzato di Sawtooth.

Hyperledger Burrow espone gli endpoint RESTful e JSON-RPC per consentire ai client di interagire con la rete blockchain e lo stato dell'applicazione trasmettendo transazioni o interrogando lo stato corrente dell'applicazione.

I Websocket consentono l'interfacciamento dei componenti per la sottoscrizione degli eventi. Ciò è particolarmente utile in quanto il motore del consenso e il motore di applicazione del contratto intelligente possono fornire risultati univocamente finalizzati alle transazioni dopo ciascun blocco.

Consenso

Il consenso è il processo attraverso il quale una rete di nodi fornisce un ordine garantito di transazioni e convalida il blocco di transazioni. Il consenso deve fornire le seguenti funzionalità di base:

Conferma la correttezza di tutte le transazioni in un blocco proposto, secondo le politiche di approvazione e consenso.
Concorda sull'ordine e la correttezza e quindi sui risultati dell'esecuzione (implica un accordo sullo stato globale).
Interfaccia e dipende dal livello smart-contract per verificare la correttezza di un insieme ordinato di transazioni in un blocco.

Confronto di tipi di consenso

Il consenso può essere implementato in diversi modi, ad esempio attraverso l'uso di algoritmi basati sulla lotteria tra cui la Prova del tempo trascorso (Poet) e la Prova di lavoro (PoW) o l'utilizzo di metodi basati sul voto, tra cui Ridondanza dei guasti bizantina (RBFT) e Paxos. Ciascuno di questi approcci si rivolge a diversi requisiti di rete e modelli di tolleranza agli errori.

Gli algoritmi basati sulla lotteria sono vantaggiosi in quanto possono scalare su un gran numero di nodi poiché il vincitore della lotteria propone un blocco e lo trasmette al resto

della rete per la convalida. D'altra parte, questi algoritmi possono portare a biforcarsi quando due "vincitori" propongono un blocco. Ogni forcella deve essere risolta, il che si traduce in un tempo più lungo per la finalità.

Gli algoritmi basati sul voto sono vantaggiosi in quanto forniscono finalità a bassa latenza. Quando la maggioranza dei nodi convalida una transazione o un blocco, il consenso esiste e si verifica la finalità. Poiché gli algoritmi basati sul voto richiedono in genere ai nodi di trasferire messaggi a ciascuno degli altri nodi sulla rete, più nodi sono presenti sulla rete, maggiore è il tempo necessario per raggiungere il consenso. Ciò si traduce in un compromesso tra scalabilità e velocità.

L'ipotesi operativa per gli sviluppatori di Hyperledger è che le reti di blockchain aziendali funzioneranno in un ambiente di fiducia parziale. Detto questo, non includiamo espressamente approcci standard di consenso alla Proof of Work con i minatori anonimi. Nella nostra valutazione, questi approcci impongono un costo troppo grande in termini di risorse e tempo per essere ottimale per le reti di blockchain aziendali.

tabella blockchain consensus bianca en

Consenso e interazione con altri strati architettonici

Mentre ci sono molti modi in cui è possibile raggiungere un consenso, la nostra analisi delle piattaforme blockchain suggerisce che il processo mostrato nella Figura 1 è comunemente usato. Questa è una visione generalizzata e i diversi framework di Hyperledger possono scegliere di implementare questi passaggi in modo diverso.

I framework blockchain aziendali Hyperledger raggiungono il consenso eseguendo due attività distinte:

1. Ordinazione di transazioni

2.Validare le transazioni

Separando logicamente queste attività, garantiamo che qualsiasi framework Hyperledger possa funzionare con qualsiasi modulo di consenso Hyperledger.

Il primo passaggio del flusso del processo di consenso sta ricevendo le transazioni dall'applicazione client. Il consenso dipende da un servizio di ordinazione per ordinare le transazioni. Il servizio di ordinazione può essere implementato in diversi modi: da un servizio centralizzato, che può essere utilizzato nello sviluppo e test, a protocolli distribuiti che si rivolgono a diversi modelli di guasto di rete e nodo. Per consentire la riservatezza delle transazioni, il servizio di ordinazione può essere indipendente dalla transazione; ovvero, il contenuto della transazione può essere sottoposto a hash o crittografato.

Le transazioni vengono inviate tramite un'interfaccia al servizio di ordinazione. Questo servizio raccoglie le transazioni in base all'algoritmo di consenso e alla politica di configurazione, che può definire un limite di tempo o specificare il numero di transazioni consentite. La maggior parte delle volte, per motivi di efficienza, invece di emettere singole transazioni, il servizio di ordinamento raggrupperà più transazioni in un unico blocco. In questo caso, il servizio di ordinazione deve imporre e trasmettere un ordine deterministico delle transazioni all'interno di ciascun blocco.

Per convalidare le transazioni, il consenso dipende dal livello del contratto intelligente perché contiene la logica aziendale dietro ciò che rende valida una transazione. Il livello di contratto intelligente convalida ogni transazione assicurando che siano conformi alla politica e al contratto specificato per la transazione. Le transazioni non valide vengono rifiutate e possono essere eliminate dall'inclusione all'interno di un blocco.

Possiamo dividere i potenziali errori di validazione in due categorie: sintassi e errori logici. Per errori di sintassi come input non validi, firma non verificabile e transazioni ripetute (a causa di errori o attacchi di replay), la transazione deve essere eliminata. La seconda categoria di errori è più complessa e dovrebbe essere guidata dalle politiche se continuare o meno l'elaborazione. Ad esempio, una transazione che comporterebbe un errore di controllo a doppia spesa o di controllo delle versioni. Potremmo voler registrare queste transazioni per il controllo se la politica lo richiede.

Il livello di consenso utilizza il livello di comunicazione per comunicare con il client e altri peer sulla rete.

Proprietà del consenso

Il consenso deve soddisfare due proprietà per garantire l'accordo tra i nodi: sicurezza e vivibilità.

Sicurezza significa che a ciascun nodo è garantita la stessa sequenza di input e risultati nello stesso output su ciascun nodo. Quando i nodi ricevono una serie identica di transazioni, si verificano le stesse modifiche di stato su ciascun nodo. L'algoritmo deve comportarsi in modo identico a un sistema a nodo singolo che esegue ciascuna transazione atomicamente una alla volta.

Liveness significa che ogni nodo non difettoso alla fine riceverà ogni transazione inviata, supponendo che la comunicazione non fallisca.

Consenso nei framework di Hyperledger

Poiché i requisiti della blockchain aziendale variano, la comunità di Hyperledger sta lavorando su diversi meccanismi di consenso e approcci di implementazione per garantire la modularità.

La Tabella 2 fornisce un confronto degli algoritmi di consenso utilizzati nei framework di Hyperledger. Apache Kafka in Hyperledger Fabric, RBFT in Hyperledger Indy e Sumeragi in Hyperledger Iroha utilizzano un approccio basato sul voto al consenso che fornisce tolleranza di errore e finalità in pochi secondi. Poet in Hyperledger Il dente di sega utilizza un approccio al consenso basato sulla lotteria che fornisce scalabilità a causa del ritardo del costo della finalità dovuto alle forcelle che devono essere risolte.