Introduzione alla filosofia e al consensus di Hyperledger Business Blockchain Design

Questo è il primo di una serie di articoli dell'Hyperledger Architecture Working Group (WG). Questi articoli descrivono un'architettura di riferimento generalizzata per le reti di blockchain autorizzate e condividono le raccomandazioni dell'Hyperledger Architecture WG con l'obiettivo finale di guidare tutti i progetti Hyperledger verso progetti modulari. Questi documenti servono anche come risorsa neutrale per gli utenti di blockchain tecnici e gli sviluppatori interessati a utilizzare le reti di blockchain autorizzate.
In questo documento iniziale, miriamo a:
1. Descrivere la filosofia di progettazione globale Hyperledger per le reti di blockchain autorizzate.
2. Spiegare in che modo il nostro approccio ottimizza lo sviluppo di tecnologie di blockchain aziendali flessibili e interoperabili.
3. Identificare i principali componenti di rete blockchain autorizzati che il WG ha identificato e continuerà a definire attraverso il suo lavoro.
4. Fornire un'architettura di riferimento generalizzata per il consensus.
5. Scoprire in che modo ciascuna struttura blockchain business Hyperledger manifesta l'architettura di riferimento.

I prossimi lavori di questa serie amplieranno l'architettura di riferimento generalizzata Hyperledger per includere i seguenti componenti blockchain aziendali: Smart Contract Layer, Communication Layer, Data Store Abstraction, Crypto Abstraction, Identity Services, Policy Services, API e Interoperation.

Informazioni sul gruppo di lavoro sull'architettura di Hyperledger

Hyperledger Architecture WG funge da forum intersettoriale per architetti e tecnologi della comunità Hyperledger per scambiarsi idee ed esplorare alternative e compromessi architettonici alternativi. Il loro obiettivo è lo sviluppo di una struttura architettonica modulare per i registri distribuiti a livello aziendale. Ciò include l'identificazione di componenti comuni e critici, fornendo una scomposizione funzionale di uno blockchain aziendale bloccato in strati e moduli, standardizzando le interfacce tra i componenti e garantendo l'interoperabilità tra i registri.

Introduzione

I requisiti blockchain aziendali variano. Alcuni usi richiedono rapidi sistemi di consensus di rete e brevi tempi di conferma dei blocchi prima di essere aggiunti alla catena. Per altri, un tempo di elaborazione più lento può essere accettabile in cambio di livelli inferiori di fiducia richiesta. Scalabilità, riservatezza, conformità, complessità del flusso di lavoro e persino requisiti di sicurezza differiscono drasticamente tra settori e usi. Ognuno di questi requisiti, e molti altri, rappresentano un punto di ottimizzazione potenzialmente unico per la tecnologia. Per questi motivi, Hyperledger consente di incubare e promuovere una gamma di tecnologie blockchain aziendali, inclusi registri distribuiti, motori intelligenti di contratti, librerie client, interfacce grafiche, librerie di utilità e applicazioni di esempio. La strategia a ombrello di Hyperledger incoraggia il riutilizzo di elementi costitutivi comuni attraverso un quadro architettonico modulare. Ciò consente una rapida innovazione della tecnologia DLD (distributed ledger technology), dei moduli funzionali comuni e delle interfacce tra di essi. I vantaggi di questo approccio modulare comprendono l'estensibilità, la flessibilità e la capacità di qualsiasi componente di essere modificato indipendentemente senza influenzare il resto del sistema.

Panoramica dell'architettura

Tutti i progetti Hyperledger seguono una filosofia di progettazione che include un approccio modulare estensibile, interoperabilità, un'enfasi su soluzioni altamente sicure, un approccio token-agnostico senza criptovaluta nativa e lo sviluppo di un'API (Application Programming Interface) ricca e facile da usare. HyperGreat Architecture WG ha distinto i seguenti componenti blockchain aziendali:
• Consensus Layer - Responsabile della generazione di un accordo sull'ordine e conferma della correttezza dell'insieme di transazioni che costituiscono un blocco.
• Smart Contract Layer - Responsabile per l'elaborazione delle richieste di transazione e per determinare se le transazioni sono valide mettendo in atto la logica di business.
• Livello di comunicazione: responsabile del trasporto di messaggi peer-to-peer tra i nodi che partecipano a un'istanza di contabilità condivisa.
• Astrazione dell'archivio dati: consente a diversi data store di essere utilizzati da altri moduli.
• Crypto Abstraction: consente di scambiare diversi algoritmi o moduli crittografici senza influire sugli altri moduli.
• Servizi di identità: consente di stabilire una radice di attendibilità durante l'installazione di un'istanza blockchain, la registrazione e la registrazione di identità o entità di sistema durante l'operazione di rete e la gestione di modifiche quali gocce, aggiunte e revoche. Inoltre, fornisce autenticazione e autorizzazione.
• Servizi di policy: responsabili della gestione delle policy di varie politiche specificate nel sistema, come la politica di approvazione, la politica di consensus o la politica di gestione del gruppo. Interfaccia e dipende da altri moduli per far rispettare le varie politiche.
• API: consente a client e applicazioni di interfacciarsi con blockchain.
• Interoperabilità - Supporta l'interoperabilità tra diverse istanze blockchain.
In questo documento, esploreremo il consensus. L'obiettivo del consensus è generare un accordo sull'ordine e convalidare la correttezza dell'insieme di transazioni che costituiscono il blocco.

Consensus

Il consensus è il processo attraverso il quale una rete di nodi fornisce un ordine garantito di transazioni e convalida il blocco di transazioni. Il consensus deve fornire le seguenti funzionalità di base:
• Conferma la correttezza di tutte le transazioni in un blocco proposto, secondo le politiche di approvazione e consensus.
• 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 tra tipi di Consensus

Il consensus può essere implementato in diversi modi, ad esempio attraverso l'uso di algoritmi basati su di una sorta di lotteria, tra cui la Proof of Elapsed Time (Poet) e la Proof of Work (PoW) o attraverso l'uso di metodi basati sul voto, tra cui Redundant Byzantine Fault Tolerance (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 eventuale differenza deve essere risolta, il che si traduce in un tempo più lungo per raggiungere il risultato finale. Gli algoritmi basati sul voto sono vantaggiosi in quanto forniscono risultati a bassa latenza. Quando la maggioranza dei nodi convalida una transazione o un blocco, il consensus esiste e si arriva al risultato (finality). 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 consensus. 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 consensus alla Proof of Work con i miner 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. La tabella 1 offre una panoramica a prima vista delle principali considerazioni e pro e contro di diversi approcci di blockchain per raggiungere il consensus.

tabella-blockchain-consensus-bianca-en
CONSENSUS2

Consensus e interazioni con altri livelli di architettura

Mentre ci sono molti modi in cui è possibile raggiungere un consensus, la nostra analisi delle piattaforme blockchain suggerisce che il processo mostrato nella Figura 1 è più 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 consensus eseguendo due attività distinte:

1. Ordine delle transazioni
2. Convalida delle transazioni

Separando logicamente queste attività, garantiamo che qualsiasi framework Hyperledger possa funzionare con qualsiasi modulo di consensus Hyperledger. Il primo passaggio del flusso del processo di consensus sta ricevendo le transazioni dall'applicazione client. Il consensus 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 consensus 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 consensus dipende dal livello dello smart contract perché contiene la logica aziendale dietro ciò che rende valida una transazione. Il livello di smart contract 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 consensus utilizza il livello di comunicazione per comunicare con il client e altri peer sulla rete.

Proprietà del consensus

Il consensus 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.

Consensus nel framework Hyperledger

Poiché i requisiti della blockchain aziendale variano, la comunità di Hyperledger sta lavorando su diversi meccanismi di consensus e approcci di implementazione per garantire la modularità. La Tabella 2 fornisce un confronto degli algoritmi di consensus 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 consensus che fornisce tolleranza di errore e finalità in pochi secondi.

table consensus

Il consensus nel consensus sul tessuto di Hyperledger in Hyperledger Fabric è suddiviso in 3 fasi: approvazione, ordine e convalida.
• L'approvazione è guidata da una politica (ad esempio m out of n signature) sulla quale i partecipanti approvano una transazione.
• La fase di ordinazione accetta le transazioni approvate e accetta l'ordine da impegnare nel libro mastro.
• La convalida prende un blocco di transazioni ordinate e convalida la correttezza dei risultati, incluso il controllo della politica di approvazione e la doppia spesa.

schema transd cons

Hyperledger Fabric supporta il servizio di consensus collegabile per tutte e 3 le fasi. Le applicazioni possono plug-in diversi modelli di approvazione, ordinazione e validazione in base alle loro esigenze. In particolare, l'API del servizio di ordinazione consente di collegare algoritmi di accordi basati su BFT. L'API del servizio di ordinazione consiste in due operazioni di base: trasmissione e consegna.
• broadcast (blob): un client lo chiama per trasmettere un blob di messaggi arbitrari per la diffusione sul canale. Questo è anche chiamato richiesta (blob) nel contesto BFT, quando si invia una richiesta a un servizio.
• deliver (seqno, prevhash, blob): il servizio di ordinamento lo chiama sul peer per consegnare il blob del messaggio con il numero di sequenza intero non negativo specificato (seqno) e l'hash del blob consegnato più di recente (prevhash). In altre parole, si tratta di un evento di output dal servizio di ordinazione. deliver () è talvolta chiamato anche notify () nei sistemi pub-sub o commit () nei sistemi BFT.
Al momento sono in fase di sviluppo diversi plug-in di ordinazione, tra cui BFT Smart, Simplified Fault Tolerance (SBFT), Honey Badger di BFT, ecc. Per Fabric v1, Apache Kafka viene fornito come implementazione di riferimento. I casi d'uso dell'applicazione e il suo modello di tolleranza d'errore dovrebbero determinare quale plugin usare.

Consensus in Hyperledger Indy

Il consensus in Hyperledger Indy si basa sulla Ridondante tolleranza ai guasti bizantini (RBFT), che è un protocollo ispirato al Plenum bizantina Fault Tolerance (Plenum). Pensa a RBFT come a molte istanze di Plenum in parallelo. Le richieste ordinate da una singola istanza chiamata master vengono utilizzate per aggiornare il libro mastro, ma le prestazioni del master in termini di throughput e latenza vengono periodicamente confrontate con le prestazioni medie di altre istanze. Se si rileva che il master è degradato, si verifica una modifica della visualizzazione che nomina un'istanza diversa rispetto al ruolo di master. Come PBFT, RBFT ha bisogno di almeno 3f + 1 nodi per gestire i nodi difettosi. La figura 3 mostra una rete di 4 nodi in grado di gestire 1 nodo difettoso, ha 2 istanze tipo PBFT in esecuzione, un master e un backup. Ogni nodo può ospitare un'istanza principale (leader).

griglia

La Figura 4 mostra una diversa visualizzazione di RBFT. Qui il client sta inviando una richiesta ai nodi. Non è necessario inviare a tutti i nodi perché l'invio a f + 1 nodi è sufficiente. Dopo aver ricevuto la richiesta del client, i nodi eseguono un processo di diffusione tramite PROPAGATE in cui ogni altro nodo viene reso consapevole della richiesta. Ogni primario crea una proposta dalle richieste ricevute chiamata PRE-PREPARA e la invia a tutti gli altri nodi. Se i nodi accettano la proposta del primario, inviano un riconoscimento alla proposta tramite un messaggio chiamato PREPARAZIONE. Una volta che un nodo riceve una proposta PRE-PREPARE e 2f PREPARA, allora ha sufficienti informazioni per accettare la proposta e invia un messaggio COMMIT. Quando un nodo riceve 2 messaggi di COMMIT 2 + 1, il gruppo di richieste può essere ordinato e aggiunto al libro mastro poiché un numero sufficiente di nodi ha concordato che la maggioranza dei nodi ha accettato la proposta. Il primario non richiede che una proposta venga completata prima di poter inviare la proposta successiva.

replicants

Hyperledger Indy utilizza RBFT per gestire l'ordine e la convalida, il che si traduce in un singolo libro mastro contenente transazioni sia ordinate sia convalidate. Diversamente da molte reti blockchain che utilizzano un protocollo BTP (Byzantine Fault Tolerance) solo per l'ordine. Queste reti lasciano che la convalida specifica del dominio avvenga dopo che le richieste sono state ordinate. Il plenum, e quindi RBFT, mantiene una proiezione del libro mastro chiamato stato. Tutte le operazioni valide e accettate eseguite possono cambiare lo stato, che viene memorizzato in un database come una raccolta di variabili e i loro valori. Lo stato è conservato in una struttura di dati autenticata crittograficamente chiamata albero Merkle Patricia, che è specificato da Ethereum. Hyperledger Indy memorizza i DID (Decentralized Identifiers) come variabili di stato con valori che includono la chiave di verifica corrente e alcune altre cose. La copia in memoria delle transazioni contabili e dello stato risultante viene ottimisticamente aggiornata durante la fase della proposta. Il primario viene aggiornato durante l'invio della proposta e i non primari vengono aggiornati mentre accettano una proposta valida. La proposta viene ordinata, quindi il libro mastro e lo stato risultante vengono impegnati. Se la proposta viene rifiutata per qualche motivo, le modifiche apportate al libro mastro e allo stato risultante vengono ripristinate. Questo aggiornamento ottimistico è necessario per proporre proposte multiple senza che le precedenti proposte siano completamente ordinate. Ad esempio, se la prima proposta conteneva una richiesta che stava creando una nuova identità Id1 sul libro mastro e la seconda proposta conteneva una richiesta che aggiungeva un attributo per Id1, quindi se lo stato non rifletteva l'esistenza di Id1, la seconda proposta sarebbe respinto. Quindi, prima che la seconda proposta sia accettata, le modifiche nella prima proposta dovrebbero essere visibili. Quando le modifiche sono state proposte, ma non ancora impegnate, si parla di una modifica non vincolante.

Consensus in Hyperroger Iroha

Hyperroger Iroha introduce un algoritmo di consensus BFT chiamato Sumeragi, che tollera f numeri di nodi difettosi bizantini in una rete, come tutti i sistemi BFT. È fortemente ispirato dall'algoritmo della catena B descritto da Duan, Meling, Peisert e Zhang (2014). Come in B-Chain, consideriamo il concetto di un ordine globale sulla convalida di pari e imposta A e B di pari, dove A è costituito dai primi 2f + 1 peer e B è costituito dal resto. Poiché sono necessarie 2f + 1 firme per confermare una transazione, nel caso normale sono coinvolti solo 2f + 1 peer nella convalida della transazione. I peer restanti si uniscono alla convalida solo quando i difetti sono esibiti in peer nel set A. Il 2 ° + 1 ° peer è chiamato il proxy tail. Per i casi normali (non di fallimento), il flusso della transazione è mostrato come in Figura 5.

iroha

Il client, che in genere sarà un server API che si interfaccia con un client dell'utente finale, invia prima una transazione al peer di convalida del lead. Questo leader verifica quindi la transazione, la ordina in coda e firma la transazione. Trasmette quindi questa transazione ai restanti peer di convalida 2f + 1. L'ordine di elaborazione dei nodi è determinato in base al sistema di reputazione del server chiamato hijiri. Hijiri calcola l'affidabilità dei server in base a tre fattori. Innanzitutto, in base al tempo in cui ciascun server si è registrato con il servizio di appartenenza. Secondo, in base al numero di transazioni riuscite elaborate da ciascun server. In terzo luogo, a seconda che siano stati rilevati errori.

Per rilevare i guasti, ogni server imposta un timer quando firma e trasmette una transazione alla coda del proxy. Se si verifica un errore in un server intermedio e una risposta non viene ricevuta prima che il timer si spenga, il server ritrasmette la transazione e la sua firma al server successivo nella catena dopo la coda del proxy. Il caso di un errore nella coda del proxy è mostrato nella Figura 6.

iroha2

Il consensus in Sumeragi viene eseguito su singole transazioni e sullo stato globale risultante dall'applicazione della transazione. Quando un peer di convalida riceve una transazione sulla rete, esegue i seguenti passi nell'ordine:
1. Convalidare la firma (o le firme, nel caso di transazioni multi-firma) della transazione.
2. Convalidare il contenuto della transazione, ove applicabile. Ad esempio, le transazioni di trasferimento devono lasciare il conto del pagatore con un saldo non negativo.
3. Applicare temporaneamente la transazione al libro mastro. Ciò comporta l'aggiornamento della radice Merkle dello stato globale.
4. Firmare la radice Merkle aggiornata e l'hash dei contenuti della transazione.
5. Trasmetti la tupla, che è un elenco di transazioni finito e ordinato.
6. Quando si sincronizzano i nodi tra loro, le parti valide dell'albero Merkle vengono condivise fino a quando le radici coincidono.

Consensus in Hyperledger Sawtooth

Hyperledger Sawtooth facilita il consensus innestabile per entrambi gli algoritmi di lotteria e di voto. Per impostazione predefinita, Hyperledger Sawtooth utilizza un algoritmo di consensus Nakamoto basato sulla lotteria chiamato PoET. Come con PoW di Bitcoin, PoET utilizza una lotteria per l'elezione dei leader basata su un tempo di attesa garantito fornito attraverso un Trusted Execution Environment (TEE) (Sandell, Bowman, & Shah, 2016). Allo scopo di raggiungere un consensus distribuito in modo efficiente, una buona funzione della lotteria ha diverse caratteristiche che sono state definite da Sandell et al. (2016) come:
• Equità: la funzione dovrebbe distribuire le elezioni dei leader tra la più ampia popolazione possibile di partecipanti.
• Investimenti - Il costo del controllo del processo elettorale dei leader dovrebbe essere proporzionale al valore ottenuto da esso.
• Verifica: dovrebbe essere relativamente semplice per tutti i partecipanti verificare che il leader sia stato legittimamente selezionato.
L'attuale implementazione di Hyperledger Sawtooth si basa su un TEE fornito da Software Guard Extensions (SGX) di Intel. Ciò garantisce la sicurezza e la casualità del processo elettorale dei leader senza richiedere il costoso investimento di potenza e hardware specializzato inerente alla maggior parte degli algoritmi "a prova". Ogni validatore di PoE richiede un tempo casuale per attendere da una funzione attendibile prima di rivendicare la leadership. Il validatore con il tempo di attesa più breve per un determinato blocco di transazione viene eletto implicitamente dal leader. La funzione "CreateTimer" crea un timer per un blocco di transazione che è stato creato dal TEE. La funzione "CheckTimer" verifica che il timer sia stato creato dal TEE e, se è scaduto, crea un attestato che può essere utilizzato per verificare che il validatore abbia, infatti, aspettato il tempo assegnato prima di rivendicare il ruolo di leader. L'algoritmo di elezione del leader del Poet soddisfa i criteri per un buon algoritmo di lotteria. Distribuisce casualmente l'elezione dei dirigenti attraverso l'intera popolazione di validatori con una distribuzione simile a quella fornita da altri algoritmi della lotteria. La probabilità di elezione è proporzionale alle risorse fornite, in cui le risorse sono processori di uso generale con un TEE. Un attestato di esecuzione fornisce informazioni per verificare che il certificato sia stato creato all'interno del TEE e che il validatore abbia atteso il tempo assegnato. Inoltre, il basso costo della partecipazione aumenta la probabilità che la popolazione dei validatori sia ampia, aumentando la robustezza dell'algoritmo di consensus.

Conclusione

In questo documento iniziale, abbiamo introdotto il framework modulare architettonico utilizzato da tutti i progetti di Hyperledger ed esplorato diversi modi in cui il consensus può essere implementato all'interno di questo framework modulare.
I takeaway principali includono:
1. La filosofia di progettazione globale Hyperledger per le reti di blockchain autorizzate segue un approccio modulare che consente estensibilità e flessibilità.
2. All'interno di questo approccio modulare, Hyperledger definisce i componenti funzionali comuni e le interfacce tra di essi, che consente a qualsiasi componente di essere modificato indipendentemente senza influire sul resto del sistema.
3. Il WG di architettura ha continuato e continuerà a definire i seguenti componenti principali per le reti di blockchain autorizzate: Consensus Layer, Smart Contract Layer, Communication Layer, Data Store Abstraction, Crypto Abstraction, Servizi di identità, Servizi di policy, API e Interoperation.
4. L'Architecture WG ha condiviso un'architettura di riferimento generalizzata per il consensus che può essere utilizzata da qualsiasi progetto Hyperledger.
5. Tessuto Hyperledger, Hyperlyger Indy, Hyperledger Iroha e Hyperledger Sawtooth manifestano ciascuno i principi dell'architettura di riferimento in modi unici.

Il confronto degli algoritmi di consensus comunemente usati con questi framework è fornito nella Tabella 1, che può essere utilizzata per determinare rapidamente i punti di forza e di debolezza degli algoritmi inclusi Kafka, RBFT, Sumeragi e PoET.
I prossimi lavori di questa serie amplieranno l'architettura di riferimento generalizzata Hyperledger per coprire tutti i componenti principali per le reti di blockchain autorizzate. Il prossimo articolo della serie coprirà lo Smart Contract Layer.