Hyperledger Architecture: Smart Contracts

Panoramica dell'architettura di Hyperledger

Come progetto ombrello, Hyperledger non ha una sola architettura di per sé. Tuttavia, tutti i progetti Hyperledger seguono una filosofia di progettazione che include un approccio modulare estendibile, interoperabilità, un'enfasi su soluzioni altamente sicure, un approccio token-agnostico senza criptovaluta nativa e facilità d'uso.
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. Leggi il documento di consenso sull'architettura Hyperledger
• Smart Contract Layer - Responsabile per l'elaborazione delle richieste di transazione e per determinare se le transazioni sono valide eseguendo 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 di varie politiche specificate nel sistema, come la politica di approvazione, la politica di consenso o la politica di gestione di 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.

Introduzione agli Smart Contracts

Uno smart contract è essenzialmente l'utilizzo di una logica aziendale in ambito blockchain.
Gli smart contracts possono essere semplici, come un aggiornamento dei dati o complessi come un contratto effettivo con le conseguenti clausole.

Ad esempio, uno smart contract può aggiornare un saldo del conto, con la convalida per assicurarsi che ci sia abbastanza denaro prima di fare un addebito.
Uno smart contract più complesso può essere scritto per stabilire che il costo di spedizione di un articolo dipende dal momento di consegna. Con i termini concordati da entrambe le parti e scritti nel libro mastro, i fondi appropriati cambiano automaticamente quando l'oggetto viene ricevuto.

Esistono due diversi tipi di smart contracts:

• Gli smart contracts installati che introducono la logica aziendale sui validatori della rete prima dell'avvio della rete stessa.
• Gli smart contracts on-chain implementano la logica aziendale come una transazione impegnata nella blockchain e quindi richiamata dalle transazioni successive. Con gli smart contracts on-chain, il codice che definisce la logica aziendale diventa parte del libro mastro.

Quali framework Hyperledger supportano gli Smart Contracts?

Quattro framework blockchain Hyperledger supportano smart contracts:
• Hyperledger Burrow
• Tessuto Hyperledger
• Hyperroger Iroha
• Hyperledger Sawtooth
In tutti questi framework, lo strato dello smart contract è responsabile dell'elaborazione delle richieste di transazione e della determinazione delle transazioni valide mediante l'esecuzione della logica di business. Ogni framework supporta gli smart contracts in un modo leggermente diverso, come vedremo in seguito.

Come vengono elaborati gli smart contracts

La Figura 1 mostra come viene elaborata una richiesta inviata ad uno smart contract. 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 dello smart contract. Quando l'interprete del contratto riceve una richiesta, verifica immediatamente e quindi respinge tutte le richieste non valide.

blockchain-grafico1-en

Gli output appropriati vengono generati se la richiesta è valida e accettata. Queste uscite includono un nuovo stato e qualsiasi effetto collaterale.

Una volta completata l'elaborazione, l'interprete confeziona il nuovo stato, un'attestazione di correttezza e qualsiasi suggerimento di ordinamento richiesto per i servizi di consenso. Questo pacchetto viene inviato al servizio di consensus per l'impegno finale verso la blockchain.

Il livello dello smart contract convalida ogni richiesta assicurandosi che sia conforme alla politica e al contratto specificato per la transazione. Le richieste non valide vengono rifiutate e possono essere eliminate dall'inclusione all'interno di un blocco, a seconda del framework.

Gli errori di convalida possono essere suddivisi in due categorie: errori di sintassi ed errori logici.

Per errori di sintassi si intendono: 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 provocasse un errore di controllo della doppia spesa o del controllo della versione, potrebbe essere necessario registrare tale richiesta per il controllo, se richiesto dalla policy.

Il risultato della convalida di una richiesta in uno smart contract è 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 consensus 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, lo smart contract 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 smart contracts, modifiche a risorse globali o anche azioni irreversibili come la distribuzione di informazioni sensibili o la spedizione di un pacchetto.

Transaction Dependencies

Tutti e quattro i framework Hyperledger che supportano gli smart contracts - 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 smart contract. Altri consentono il batching di transazioni su più smart contract. Pertanto, gli smart contracts 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.
Con le dipendenze acicliche, qualsiasi parte della sequenza può essere inclusa nel blocco, purché le transazioni siano incluse in base al grafico delle dipendenze. Ad esempio, se la transazione B dipende dalla transazione A, allora la transazione A deve essere impegnata prima della transazione B.
Con dipendenze implicite, i cicli possono essere complessi da risolvere, il che può impedire che determinate transazioni vengano convalidate in parallelo e confermate. D'altra parte, riferimenti di dipendenza espliciti possono consentire l'esecuzione parallela di transazioni non in conflitto all'interno dello stesso blocco.

Come gli Smart Contract interagiscono con gli altri livelli di architettura

blockchain-grafico-2-trasparente (1)

La Figura 2 mostra in che modo gli smart contracts si adattano agli altri livelli architettonici di 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 smart contract funziona a stretto contatto con il livello di consensus. Nello specifico, lo strato di contratto intelligente riceve una proposta dal livello di consensus. 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 smart contract utilizza lo stato corrente del libro mastro e l'input dal livello di consensus per convalidare la transazione.
Durante l'elaborazione della transazione, il livello dello smart contract utilizza il livello dei servizi di identità per autenticare e autorizzare l'entità che chiede di eseguire il contratto intelligente. Ciò garantisce due cose: che l'entità sia nota sulla rete blockchain e che l'entità abbia l'accesso appropriato per eseguire lo smart contract. 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 dello smart contract restituisce se la transazione è stata accettata o rifiutata. Se la transazione è stata accettata, lo strato dello smart contract 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 dai peer.

Integrità e disponibilità di Smart Contract

Per garantire l'integrità e la disponibilità della rete blockchain e del livello dello smart contract, le blockchain aziendali devono controllare l'accesso a determinate risorse. Poiché gli smart contracts 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 viene 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 gli smart contracts possano eseguire solo le funzioni necessarie per eseguire una determinata transazione. Senza garanzie, codice dello smart contract malevolo o errato potrebbe corrompere la rete, rischiando il furto o l'esposizione di dati privati.
Una varietà di tecniche collaudate 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, uno smart contract 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é gli smart contracts 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.

Smart Contracts nei framework di Hyperledger

blckchain-tabella-1-en

Poiché le diverse aziende hanno requisiti diversi per blockchain, la comunità di Hyperledger sta lavorando su diversi modi per implementare gli smart contracts.
La Tabella 1 mette a confronto le implementazioni dello smart contract utilizzate nei framework Hyperledger. Per ogni framework, la tabella elenca la tecnologia dello smart contract utilizzata, il tipo di contratto (installato o on-chain) e il linguaggio di programmazione principale utilizzato per scrivere gli smart contracts.

Smart Contracts in Hyperledger Burrow

Hyperledger Burrow è una macchina a smart contract autorizzata. Fornisce un client blockchain modulare con un interprete di contratto 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 consensus di Tendermint su un'interfaccia di consensus 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 o corrispondono a una coppia di chiavi pubblica-privata.
Una transazione che richiede il codice del contratto in un determinato account attiverà l'esecuzione del codice di quell'account in una macchina virtuale autorizzata.
Il motore di applicazione del contratto 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 in un determinato account attiverà l'esecuzione del codice di quell'account in una macchina virtuale autorizzata.

Secure Native Functions

Le funzioni native sicure forniscono le regole di base che devono seguire tutti gli account e tutto il codice di contratto. 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 dello smart contract.

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 smart contracts. 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. Sono in corso degli sforzi 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 su ruoli possono essere sfruttate tramite i ruoli di Hyperledger Burrow su ciascun account. I ruoli possono essere aggiornati tramite transazioni discrete o smart contracts.
Inoltre, Hyperledger Burrow espone la possibilità di smart contracts 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 smart contracts compilati per l'EVM autorizzato e formulare transazioni che chiamano smart contracts.
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.

Gateway

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.

Firma

Hyperledger Burrow accetta transazioni firmate e firmate lato client. È disponibile un'interfaccia per la firma remota. Le soluzioni di firma esterne sono fondamentali per gli utenti di Hyperledger Burrow poiché consentono ai nodi blockchain di funzionare su hardware di base.

Interfacce

Hyperledger Burrow utilizza anche interfacce di avvio e di runtime, in gran parte tramite file letti dal nodo blockchain all'avvio. Naturalmente, Burrow include anche una chiamata a procedura remota (RPC) che consente l'interfacciamento con il nodo durante il runtime.

Smart contracts in tessuto Hyperledger

Un contratto intelligente in Hyperledger Fabric è un programma, chiamato chaincode. Chaincode può essere scritto in Go, JavaScript (node.js) e infine in altri linguaggi di programmazione come Java che implementano un'interfaccia prescritta. Chaincode viene eseguito in un contenitore Docker protetto isolato dal processo di peer di approvazione. Chaincode inizializza e gestisce lo stato di ledger tramite le transazioni inoltrate dalle applicazioni.

Un chacode in genere gestisce la logica aziendale che i membri della rete hanno accettato. Lo stato creato da un chaincode è limitato esclusivamente a quel chaincode e non è possibile accedervi direttamente da un altro chacode. Tuttavia, con l'autorizzazione appropriata, un chaincode nella stessa rete può richiamare un altro chacode per accedere al suo stato.
Ci sono due diversi tipi di chaincode da considerare:
• Chaincode di sistema
• Chaincode dell'applicazione
Il chacoding di sistema in genere gestisce le transazioni relative al sistema come la gestione del ciclo di vita e la configurazione dei criteri. Tuttavia, l'API di chaincode del sistema è aperta agli utenti per implementare anche le proprie esigenze applicative.
Il chacoding dell'applicazione gestisce gli stati dell'applicazione sul libro mastro, incluse le risorse digitali o i record di dati arbitrari.
Un chaincode inizia con un pacchetto che incapsula i metadati critici relativi al chaincode, inclusi il nome, la versione e le firme della controparte per garantire l'integrità del codice e dei metadati. Il pacchetto chaincode viene quindi installato sui nodi di rete delle controparti.
Un membro appropriato della rete (come controllato dalla configurazione della politica) attiva il chaincode inviando una transazione di istanziazione alla rete. Se la transazione è approvata, il chaincode entra in uno stato attivo in cui può ricevere transazioni dagli utenti tramite applicazioni client.
Tutte le transazioni chaincode che vengono convalidate vengono aggiunte al libro mastro condiviso. Queste transazioni possono quindi modificare lo stato del mondo di conseguenza. Ogni volta che è stato istanziato un chacode, può essere aggiornato tramite una transazione di aggiornamento.
Utilizzo di Chaincode per sviluppare contratti aziendali e applicazioni decentralizzate
Esistono in genere due modi per sviluppare contratti commerciali per Hyperledger Fabric:
• Per codificare i singoli contratti in istanze autonome di chaincode
• Utilizzare un codice a barre per gestire tutti i contratti (di determinati tipi) e far esporre le API per gestire il ciclo di vita di tali contratti. Questo secondo approccio è probabilmente più efficiente.
Utilizzo di Chaincode per definire e gestire le risorse
Gli utenti di Hyperledger Fabric possono anche utilizzare chaincode per definire le risorse e la logica che le gestisce.

Nella maggior parte delle soluzioni blockchain, ci sono due approcci popolari alla definizione delle risorse:
• Modello UTXO stateless (output della transazione non speso), in cui i saldi dei conti sono codificati nei record delle transazioni precedenti
• Il modello dell'account, in cui i saldi dei conti sono conservati nello spazio di archiviazione di stato sul registro
Ogni approccio ha vantaggi e svantaggi. Hyperledger Fabric non richiede l'uno sull'altro. Invece, assicura che entrambi gli approcci siano facili da implementare.

Smart contracts in Hyperledger Indy

Hyperledger Indy non ospita smart contracts. Anziché archiviare dati nel libro mastro e quindi fornire accesso a tali dati tramite smart contracts, Indy consente agli utenti di possedere i dati e condividerli in modo tale da preservare la loro privacy.
Le identità di Hyperledger Indy possono essere referenziate in smart contracts da altri sistemi. Ciò consente a Indy di fornire qualsiasi sistema di registro distribuito con un sistema di identità decentralizzata di prim'ordine.
Hyperledger Indy supporta plug-in che consentono il supporto di nuove transazioni senza toccare i componenti principali del codebase. Un esempio potrebbe essere la creazione di una semplice criptovaluta su Indy.

Smart contracts in Hyperledger Ir0ha

Al momento della pubblicazione, la documentazione di Hyperledger Iroha veniva aggiornata per riflettere le ultime funzionalità del contratto intelligente. Al termine, questa descrizione sarà disponibile su hyperledger.org/projects/iroha.

Smart Contracts in Hyperledger Sawtooth

Hyperledger Sawtooth è un progetto di contabilità distribuita dedicato a rendere sicuri i smart contracts, in particolare per uso aziendale. Supporta entrambi i tipi di smart contracts: installato e onchain. Gli sviluppatori possono scegliere tra sette lingue per sviluppare smart contracts in Sawtooth.

Smart Contracts installati con famiglie di transazioni

Qualsiasi linguaggio completamente programmabile presenta alcuni rischi. Per limitare questi rischi, altre reti di blockchain specificheranno la semantica della transazione fissa. Queste reti possono utilizzare famiglie di transazioni che supportano solo determinate operazioni consentite. In questo contesto, puoi pensare a una famiglia di transazioni come un'applicazione distribuita.
Un semplice esempio è la famiglia di transazioni IntegerKey. Ciò fornisce solo tre operazioni: incremento, decremento e impostazione. Con solo tre operazioni e nessun ciclo, questa famiglia aiuta a prevenire eventuali problemi di script di transazione intenzionali o accidentali.

Un altro esempio è la famiglia di transazioni Settings, che può essere utilizzata per controllare la stessa rete di blockchain, comprese specifiche come il consenso utilizzato e il tempo di blocco interno.
Un esempio sofisticato che blocca la sintassi arbitraria è la famiglia delle transazioni della supply chain. La semantica di quella famiglia include circa 20 operazioni necessarie per rintracciare la provenienza e altre informazioni contestuali di qualsiasi risorsa, ma non ulteriori operazioni che potrebbero essere utilizzate in modo improprio, intenzionalmente o per caso.
Qualsiasi famiglia di transazioni può essere distribuita con Hyperledger Sawtooth, purché questa famiglia supporti l'API della famiglia di transazione. Questa è una semplice API che supporta alcune operazioni come ottenere lo stato per recuperare qualcosa dal registro e impostare lo stato per impostare qualcosa nel registro.

Le famiglie di transazioni possono essere scritte in quasi tutti i linguaggi, inclusi C ++, Go, Java, JavaScript, Python, Rust e Solidity tramite Seth. Le famiglie di transazioni esistenti che supportano l'API includono Blockinfo, Identity, IntegerKey, Settings, Smallbank, Validator registry e XO.
La motivazione dietro le famiglie di transazioni è quella di consentire alle aziende di scegliere il livello di versatilità e rischio che è giusto per la loro rete. Uno dei vantaggi del concetto di famiglia delle transazioni - rispetto alle transazioni in catena - è che un errore super-critico può solo uccidere il processo della famiglia delle transazioni. Il resto del validatore e tutte le altre famiglie di transazioni possono continuare a funzionare. Al contrario, un bug super-critico in esecuzione su catena potrebbe uccidere l'intero nodo.

Smart Contracts a catena con la famiglia di transazioni Seth

I smart contracts su catena vengono gestiti collegando l'Hyperledger Burrow Ethereum Virtual Machine (EVM) al nodo di convalida Sawtooth Hyperledger. Una volta installato, i smart contracts possono essere scritti con il codice Solidity su Hyperledger Sawtooth utilizzando la famiglia di transazioni Sawtooth-Ethereum (Seth) e il processore di transazione. Ciò consente smart contracts completamente programmabili. Il comando seth può essere utilizzato per interagire con la famiglia di transazioni Seth tramite un'interfaccia a riga di comando. Ciò consente di caricare ed eseguire smart contracts, interrogare i dati associati a un contratto e generare chiavi nel formato utilizzato da seth. I contratti sono compilati in Hyperledger Sawtooth con il comando seth load, che ha un flag -init che accetta come argomento un array di byte con codifica esadecimale. Questa stringa è interpretata come il codice di creazione del contratto. Il compilatore solc può essere utilizzato per generare questa stringa per un contratto intelligente Solidity.
I contratti in Solidity, che possono essere compilati in Hyperledger Sawtooth, sono simili alle classi in linguaggi orientati agli oggetti. Contengono dati persistenti nelle variabili di stato e funzioni che possono modificare queste variabili. Chiamare una funzione su un contratto diverso esegue una chiamata di funzione EVM e cambia il contesto in modo che le variabili di stato non siano accessibili.
La creazione di contratti è preferibile utilizzando l'API JavaScript web.js. Quando viene creato un contratto, con lo stesso nome del contratto chiamato "costruttore" può essere eseguita una volta. Il costruttore è facoltativo e solo un costruttore è consentito, quindi il sovraccarico non è supportato.

Se un contratto vuole creare un altro contratto, il codice sorgente (e il codice binario) del contratto appena creato deve essere noto al creatore. Ciò significa che le dipendenze di creazione cicliche non sono possibili.

Conclusione

Questo documento esplora l'architettura modulare utilizzata da tutti i progetti Hyperledger e ha esaminato i diversi modi in cui i smart contracts possono essere implementati all'interno di questo framework modulare.
I takeaway principali includono:
1. Il WG Architecture 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.
2. Architecture WG ha condiviso un'architettura di riferimento generalizzata per i smart contracts che possono essere utilizzati da qualsiasi progetto Hyperledger.
3. Hyperledger Burrow, Hyperledger Fabric, Hyperledger Iroha e Hyperledger Sawtooth manifestano ciascuno i principi dell'architettura di riferimento in modi unici. La tabella 1 mette a confronto il modo in cui vengono utilizzati i smart contracts all'interno di ciascuno di questi quadri.

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 riguarderà i servizi di identità.

Reti blockchain autorizzate

I requisiti della Blockchain variano a seconda del business e dei settori. Alcuni usi richiedono rapidi sistemi di consenso 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.
Riservatezza, conformità, scalabilità, flusso di lavoro e 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.