Confronto tra Ethereum, Hyperledger Fabric e Corda

Dai white paper di Hyperledger Fabric, R3 Corda (in seguito, rispettivamente, Fabric e Corda, rispettivamente) ed Ethereum diventa ovvio che queste strutture hanno in mente visioni molto diverse rispetto a possibili campi di applicazione. Lo sviluppo di Fabric e Corda è guidato da casi d'uso concreti, mentre i casi d'uso di Corda provengono dal settore dei servizi finanziari. Di conseguenza, è qui che Corda vede il suo principale campo di applicazione. Al contrario, Fabric intende fornire un'architettura modulare ed estensibile che possa essere impiegata in vari settori, dal settore bancario e sanitario alle catene di approvvigionamento. Ethereum si presenta inoltre completamente indipendente da ogni specifico campo di applicazione. Tuttavia, contrariamente a Fabric, non è la modularità a distinguersi, ma la fornitura di una piattaforma generica per tutti i tipi di transazioni e applicazioni.

 

Participazione al peers

Con l'archiviazione dati centrale convenzionale, solo una singola entità, il proprietario, conserva una copia del database sottostante, ad es. un libro mastro. Di conseguenza, questa entità controlla quali dati sono forniti e quali altre entità sono autorizzate a contribuire. Con l'avvento della DLT questo cambia radicalmente a favore dell'archiviazione dei dati distribuiti in cui più entità detengono una copia del database sottostante e sono naturalmente autorizzati a contribuire. Tutte le entità che partecipano all'archiviazione dei dati distribuiti formano una rete di cosiddetti nodi o peer. A causa della memorizzazione dei dati distribuiti, si pone la difficoltà di assicurare che tutti i nodi concordino su una verità comune, ad es. la correttezza di un libro mastro, in quanto le modifiche apportate da un nodo devono essere propagate a tutti gli altri nodi peer della rete. Il risultato di arrivare a una verità comune è chiamato consenso tra i nodi ed è descritto di seguito.
Per quanto riguarda la partecipazione al consensus, ci sono due modalità di funzionamento: senza permesso e permesso. Se la partecipazione è senza autorizzazione, chiunque è autorizzato a partecipare alla rete. Questa modalità è vera per Ethereum come blockchain pubblico. D'altra parte, se la partecipazione è autorizzata, i partecipanti vengono selezionati in anticipo e l'accesso alla rete è limitato a questi solo. Questo è vero per Fabric e Corda. La modalità di partecipazione, senza permesso o permesso, ha un profondo impatto sul modo in cui viene raggiunto il consenso.

Consensus

Ethereum

Con Ethereum, tutti i partecipanti devono raggiungere un consensus sull'ordine di tutte le transazioni che hanno avuto luogo, indipendentemente dal fatto che un partecipante abbia preso parte a una particolare transazione o meno. L'ordine delle transazioni è fondamentale per lo stato coerente del libro mastro. Se non è possibile stabilire un ordine definitivo di transazioni, è possibile che si verifichino duplicazioni, ovvero due transazioni parallele trasferiscono la stessa moneta a destinatari diversi, ricavando così denaro dal nulla. Poiché la rete potrebbe coinvolgere le parti reciprocamente diffidenti e anonime, è necessario utilizzare un meccanismo di consensus che protegga il registro dai partecipanti fraudolenti o sfavorevoli che tentano di spendere due volte. Nell'attuale implementazione di Ethereum, questo meccanismo è stabilito dal mining basato sullo schema di prova del lavoro (PoW). Tutti i partecipanti devono concordare un libro mastro comune e tutti i partecipanti hanno accesso a tutte le voci registrate. Le conseguenze sono che PoW influisce negativamente sulle prestazioni dell'elaborazione delle transazioni. Per quanto riguarda i dati archiviati nel libro mastro, anche se i record sono resi anonimi, sono comunque accessibili a tutti i partecipanti, il che è problematico per le applicazioni che richiedono un grado più elevato di privacy.
In contrasto con Ethereum, l'interpretazione del consensus di Fabric e Corda è più raffinata e non si riduce semplicemente al mining basato sul PoW o su un suo derivato. A causa del funzionamento in modalità consentita, Fabric e Corda forniscono un controllo dell'accesso più dettagliato ai record e quindi migliorano la privacy.

Fabric

La comprensione del consensus da parte di Fabric è ampia e comprende l'intero flusso di transazioni, a partire dalla proposta di una transazione alla rete per trasferirla al registro. Inoltre, i nodi assumono ruoli e compiti diversi nel processo di raggiungimento del consenso. Ciò contrasta con Ethereum in cui i ruoli e i compiti dei nodi che partecipano al raggiungimento del consensus sono identici.
All'interno di Fabric, i nodi sono differenziati in base al fatto che siano client, peer o ordinatori. Un client agisce per conto di un utente finale e crea e quindi invoca transazioni. Comunicano con entrambi i pari e gli ordinatori. I peer gestiscono il libro mastro e ricevono i messaggi di aggiornamento ordinati dai commissari per l'accettazione di nuove transazioni nel libro mastro. Gli endorser sono un tipo speciale di peers, mentre il loro compito è quello di sostenere una transazione controllando se soddisfano le condizioni necessarie e sufficienti (ad esempio la fornitura delle firme richieste). Gli utenti forniscono un canale di comunicazione a clienti e colleghi tramite il quale possono essere trasmessi messaggi contenenti transazioni. Rispetto al consenso in particolare, i canali assicurano che tutti i peer connessi ricevano esattamente gli stessi messaggi con lo stesso ordine logico

La modalità di partecipazione, senza permesso o permesso, ha un profondo impatto sul modo in cui viene raggiunto il consenso.

A questo punto, si pone il problema che potrebbero verificarsi errori nell'erogazione di messaggi quando vengono utilizzati molti ordinatori reciprocamente non fidati. Di conseguenza, un algoritmo di consensus deve essere utilizzato al fine di raggiungere il consensus nonostante i difetti, ad es. ordine incoerente di messaggi, rendendo così tollerante la replica dei led di registro distribuiti. Con Fabric, l'algoritmo utilizzato è "pluggable", il che significa che in base ai requisiti specifici dell'applicazione possono essere utilizzati vari algoritmi. Ad esempio, per far fronte a errori di replica casuali o dannosi, come descritto sopra, potrebbe essere utilizzata una variante degli algoritmi di tolleranza ai guasti bizantina (BFT). Inoltre, i flussi dei messaggi delle partizioni dei canali, il che significa che i client vedono solo i messaggi e le transazioni associate dei canali a cui sono connessi e non sono a conoscenza di altri canali. In questo modo, l'accesso alle transazioni è limitato alle parti coinvolte solo con la conseguenza che il consensus deve essere raggiunto solo a livello di transazione e non a livello di capo come con Ethereum.

I ruoli dei nodi descritti sopra sono ora descritti nel contesto del flusso di transazioni: un client invia una transazione ai sostenitori connessi per avviare un aggiornamento del libro mastro. Tutti i sostenitori devono concordare la transazione proposta, quindi è necessario raggiungere una sorta di consenso per quanto riguarda l'aggiornamento del libro mastro proposto. Il cliente ora raccoglie successivamente l'approvazione di tutti gli endorser. La transazione approvata viene ora inviata ai clienti collegati che raggiungono nuovamente il consensus. Successivamente, la transazione viene inoltrata ai peer che detengono il libro mastro per aver commesso la transazione.

Senza andare oltre nei dettagli, diventa chiaro che Fabric consente un controllo preciso sul consenso e l'accesso limitato alle transazioni, il che si traduce in una migliore scalabilità delle prestazioni e privacy.

Corda

Simile a Fabric, il consensus in Corda viene raggiunto anche a livello di transazione coinvolgendo solo le parti. Soggetta al consensus è la validità della transazione e l'unicità della transazione. La validità è garantita dall'esecuzione del codice del contratto intelligente (i contratti intelligenti sono descritti in dettaglio di seguito) associati a una transazione, controllando tutte le firme richieste e assicurando che tutte le transazioni cui si fa riferimento siano valide. L'unicità riguarda gli stati di input di una transazione. Nello specifico, è necessario garantire che la transazione in questione sia il consumatore unico di tutti i suoi stati di input. In altre parole, non esiste altra transazione che consuma nessuno degli stessi stati. La ragione di ciò è evitare il doppio spendere. Il consensus sull'unicità è raggiunto tra i partecipanti chiamati nodi, mentre l'algoritmo utilizzato è "collegabile" come con Fabric. Quindi, ancora una volta potrebbe essere usato un algoritmo BFT.

Smart contracts

Il termine "smart contracts" causa notevoli incomprensioni quando viene affrontato per la prima volta in quanto evoca l'idea di una sorta di contratto che agisce in modo intelligente per conto di qualcuno. La natura del contratto, tuttavia, rimane vaga, ma sembra essere intuitivamente collegata a questioni legali. Ciò detto, i contratti focali non sono né intelligenti, nel senso che sono ad es. spinti dall'intelligenza artificiale, almeno non ancora, né generalmente codificano obblighi e diritti legalmente vincolanti. Dal punto di vista terminologico, esistono due diversi modi in cui viene comunemente utilizzato il termine "contratti intelligenti". Il primo si riferisce al codice del contratto intelligente, il secondo ai contratti legali intelligenti, due distinzioni che si dimostrano utili nel contesto di questo confronto.
Il codice contrattuale intelligente indica semplicemente il software scritto in un linguaggio di programmazione. Agisce come un agente software o delegato del partito che lo ha assunto con l'intenzione di adempiere a determinati obblighi, esercita i diritti e può assumere il controllo delle risorse all'interno di un libro mastro distribuito in modo automatizzato. Quindi, assume compiti e responsabilità nel mondo del libro mastro distribuito eseguendo il codice che modella o emula la logica del contratto nel mondo reale, sebbene la sua giustificazione legale possa non essere chiara.

Il codice contrattuale intelligente indica semplicemente il software scritto in un linguaggio di programmazione

Tutti i DLT presentano contratti intelligenti nel senso di un codice di contratto intelligente che può essere scritto in Go o Java per Fabric, in Solidity per Ethereum e in Java o Kotlin per Corda. In Fabric, il termine "chaincode" è usato come sinonimo di contratto intelligente. Come esempio illustrativo, al lettore viene ricordato l'utilizzo di un codice di contratto intelligente nel meccanismo di consenso di Corda al fine di garantire la validità della transazione. Tuttavia, c'è una notevole differenza tra Fabric ed Ethereum da un lato e Corda dall'altro che è collegato al secondo modo in cui viene utilizzato il termine "smart contracts".

In Corda, i contratti intelligenti non consistono solo in codice, ma in aggiunta sono autorizzati a contenere prose legali. Così sopra i contratti legali intelligenti sono prose legali che sono formulate in modo che possano essere espresse e implementate nel codice di contratto intelligente. La logica alla base di questo è dare al codice la legittimità che è radicata nella prosa legale associata. Tale costrutto si chiama Ricardian Contract. A questo punto, diventa nuovamente chiaro che Corda è stata esplicitamente progettata per rendere conto dell'ambiente altamente regolamentato del settore dei servizi finanziari. Sia Fabric che Ethereum mancano di questa funzionalità.

Valuta incorporata

Un'altra differenza degna di nota è che Ethereum presenta una criptovaluta incorporata chiamata Ether. È utilizzato per pagare i premi ai nodi che contribuiscono a raggiungere il consenso mediante il mining dei blocchi e per pagare le commissioni di transazione. Pertanto è possibile creare app decentralizzate (DApp) per Ethereum che consentono transazioni monetarie. Inoltre, è possibile creare un token digitale per casi di utilizzo personalizzato implementando un contratto intelligente conforme a uno standard predefinito. In questo modo è possibile definire valute o attività proprie.
Tessuto e Corda non richiedono una criptovaluta incorporata poiché il consenso non viene raggiunto tramite il mining. Con Fabric, tuttavia, è possibile sviluppare una valuta nativa o un token digitale con chaincode. Con Corda, una creazione di valute digitali o token non è destinata.

Riepilogo: piattaforma personalizzata o generica

Per riassumere, i DLT esaminati coprono un continuum. Da un lato, c'è Fabric ed Ethereum. Entrambi sono altamente flessibili, ma in diversi aspetti. Il potente motore di smart contracts di Ethereum lo rende una piattaforma generica per qualsiasi tipo di applicazione. Tuttavia, il modo di operare senza autorizzazione di Ethereum e la sua totale trasparenza avvengono a scapito della scalabilità delle prestazioni e della privacy. Fabric risolve la scalabilità delle prestazioni e i problemi di privacy con modalità di funzionamento autorizzate e in particolare utilizzando un algoritmo BFT e un controllo di accesso a grana fine. Inoltre, l'architettura modulare consente a Fabric di essere personalizzato su una moltitudine di applicazioni. È possibile tracciare un'analogia con una cassetta degli attrezzi versatile.

Corda si trova all'altra estremità. È stato progettato consapevolmente come DLT per il settore dei servizi finanziari. In particolare, prende in considerazione l'ambiente altamente regolamentato aumentando i contratti intelligenti con la prosa legale.
Apparentemente, l'attenzione di Corda esclusivamente sulle transazioni di servizi finanziari ha semplificato il suo progetto architettonico rispetto a Fabric. Pertanto, potrebbe offrire un'esperienza più immediata. Tuttavia, potrebbe essere possibile che Fabric, a causa della sua modularità, possa essere adattato per assomigliare al set di funzionalità di Corda. Esistono degli sforzi che cercano di integrare Corda nel progetto Hyperledger. Pertanto, Corda non può essere visto come un concorrente di Fabric ma più come un complemento.