Una piattaforma blockchain per l'impresa
Buon pomeriggio, cari lettori, mi chiamo Nikolai Nefedov, sono uno specialista tecnico IBM, in questo articolo vorrei presentarvi la piattaforma blockchain - Hyperledger Fabric. La piattaforma è destinata alla creazione di applicazioni aziendali di livello aziendale (classe Enterprise). Il livello dell'articolo è per lettori impreparati con una conoscenza di base delle tecnologie informatiche.
Hyperledger Fabric è un progetto open source, uno dei rami del progetto open source Hyperledger, un consorzio della Linux Foundation. Hyperledger Fabric è stato originariamente lanciato da Digital Assets e IBM. La caratteristica principale della piattaforma Hyperledger Fabric è il suo focus sulle applicazioni aziendali. Pertanto, la piattaforma è stata sviluppata tenendo conto dell'elevata velocità delle transazioni e del loro basso costo, nonché dell'identificazione di tutti i partecipanti. Questi vantaggi si ottengono separando il servizio di verifica delle transazioni e formando nuovi blocchi del registro distribuito, nonché utilizzando un'autorità di certificazione e autorizzando i partecipanti.
Il mio articolo fa parte di una serie di articoli su Hyperledger Fabric in cui descriviamo il progetto di un sistema per la registrazione degli studenti che entrano in un'università.
Architettura generale di Hyperledger Fabric
Hyperledger Fabric è una rete blockchain distribuita costituita da vari componenti funzionali installati sui nodi di rete. I componenti Hyperledger Fabric sono contenitori Docker che possono essere scaricati gratuitamente da DockerHub. Hyperledger Fabric può anche essere eseguito in un ambiente Kubernetes.
Per scrivere contratti intelligenti (chaincode nel contesto di Hyperledger Fabric), abbiamo utilizzato Golang (sebbene Hyperledger Fabric ti consenta di utilizzare altri linguaggi). Per sviluppare un'applicazione personalizzata, nel nostro caso, è stato utilizzato Node.js con il corrispondente Hyperledger Fabric SDK.
I nodi eseguono la logica aziendale (contratto intelligente) - chaincode, memorizzano lo stato del registro distribuito (dati del libro mastro) ed eseguono altri servizi di sistema della piattaforma. Un nodo è solo un'unità logica, possono esistere diversi nodi sullo stesso server fisico. Molto più importante è come sono raggruppati i nodi (Trusted domain) e a quali funzioni della rete blockchain sono associati.
L'architettura generale è simile a questa:
Figura 1. Architettura generale di Hyperledger Fabric
L'applicazione utente (Submitting Client) è un'applicazione con cui gli utenti lavorano con la rete blockchain. Per funzionare, è necessario passare attraverso l'autorizzazione e disporre dei diritti appropriati per vari tipi di azioni sulla rete.
I peer (nodi) hanno diversi ruoli:
- Endorsing Peer è un nodo che simula l'esecuzione di una transazione (esegue il codice dello smart contract). Dopo aver convalidato ed eseguito lo smart contract, il nodo restituisce i risultati dell'esecuzione all'applicazione client insieme alla sua firma.
- Ordering Service è un servizio distribuito su più nodi, viene utilizzato per formare nuovi blocchi del libro mastro distribuito e creare una sequenza per l'esecuzione delle transazioni. Il servizio di ordinazione non aggiunge nuovi blocchi al registro (spostato in commit peer per prestazioni migliori).
- Commiting Peer: un nodo che contiene un registro distribuito e aggiunge nuovi blocchi al registro (che sono stati formati dal servizio di ordinazione). Tutti i Commiting Peer contengono una copia locale del libro mastro distribuito. Il Commiting Peer, prima di aggiungere un nuovo blocco localmente, verifica la validità di tutte le transazioni all'interno del blocco.
La politica di approvazione è una politica per il controllo della validità di una transazione. Queste politiche definiscono l'insieme necessario di nodi su cui deve essere eseguito lo smart contract affinché la transazione sia riconosciuta come valida.
Il registro distribuito - Lerger - si compone di due parti: WolrldState (chiamato anche State DataBase) e BlockChain.
BlockChain è una catena di blocchi che memorizza i record di tutte le modifiche apportate agli oggetti del registro distribuito.
WolrldState è un componente del registro distribuito che memorizza i valori correnti (estremi) di tutti gli oggetti del registro distribuiti.
WorldState è un database, nella versione base - LevelDB o più complessa - CouchDB, che contiene coppie chiave-valore, ad esempio: Nome - Ivan, Cognome - Ivanov, data di registrazione nel sistema - 12.12.21/17.12.1961/XNUMX, data di nascita - XNUMX/XNUMX/XNUMX, ecc. WorldState e il libro mastro distribuito devono essere coerenti tra tutti i membri di un determinato canale.
Poiché Hyperledger Fabric è una rete in cui tutti i partecipanti sono conosciuti e autenticati, qui viene utilizzata un'autorità di certificazione dedicata: CA (Autorità di certificazione). CA opera sulla base dello standard X.509 e dell'infrastruttura a chiave pubblica - PKI.
Membership Service è un servizio attraverso il quale i membri verificano che un oggetto appartenga a una particolare organizzazione o canale.
Una transazione è, nella maggior parte dei casi, un record di nuovi dati in un libro mastro distribuito.
Sono presenti anche transazioni per la creazione di canali o smart contract. La transazione viene avviata dall'applicazione utente e termina con una scrittura nel libro mastro distribuito.
Channel (Channel) è una sottorete chiusa composta da due o più partecipanti alla rete blockchain, progettata per condurre transazioni riservate all'interno di una cerchia limitata, ma nota, di partecipanti. Il canale è determinato dai partecipanti, dal registro distribuito, dai contratti intelligenti, dal servizio di ordinazione, da WorldState. Ogni membro del canale deve essere autorizzato ad accedere al canale e avere il diritto di eseguire vari tipi di transazioni. L'autorizzazione viene eseguita utilizzando il servizio di appartenenza.
Tipico scenario di esecuzione della transazione
Successivamente, vorrei parlare di uno scenario tipico per l'esecuzione di una transazione utilizzando l'esempio del nostro progetto.
Come parte del nostro progetto interno, abbiamo creato una rete Hyperledger Fabric, progettata per registrare e registrare gli studenti che entrano nelle università. La nostra rete è composta da due organizzazioni, di proprietà dell'Università A e dell'Università B. Ogni organizzazione contiene un'applicazione client, nonché il proprio Peer di impegno e di approvazione. Utilizziamo anche i servizi comuni di Ordering Service, Memebership Service e Certification Authority.
1) Avvio della transazione
L'applicazione utente, utilizzando Hyperledger Fabric SDK, avvia una richiesta di transazione e invia la richiesta ai nodi con smart contract. La richiesta può essere quella di modificare o leggere da un libro mastro distribuito (Ledger). Se consideriamo un esempio della nostra configurazione di prova del sistema per la contabilità degli studenti universitari, allora l'applicazione client invia una richiesta di transazione ai nodi delle università A e B, che sono inclusi nella politica di Endorsement del cosiddetto smart contract. Il nodo A è un nodo che si trova nell'università che registra uno studente in arrivo e il nodo B è un nodo che si trova in un'altra università. Affinché una transazione venga salvata su un libro mastro distribuito, è necessario che tutti i nodi che, secondo la business logic, devono approvare la transazione, eseguano con successo smart contract con lo stesso risultato. L'applicazione utente del nodo A, utilizzando gli strumenti Hyperledger Fabric SDK, riceve la policy di approvazione (policy di approvazione) e scopre a quali nodi inviare una richiesta di transazione. Questa è una richiesta per chiamare (invocare) un determinato contratto intelligente (funzione chaincode) per leggere o scrivere determinati dati nel libro mastro distribuito. Tecnicamente, l'SDK del client utilizza la funzione corrispondente, la cui API viene passata a un oggetto con parametri di transazione, aggiunge anche una firma del client e invia questi dati tramite buffer di protocollo su gRPC ai nodi appropriati (peer di approvazione).
Figura 2. Avvio della transazione
2) Esecuzione di contratti intelligenti
I nodi (Endorsing Peer), dopo aver ricevuto una richiesta per condurre una transazione, controllano la firma del cliente e se tutto è in ordine, prendono un oggetto con i dati della richiesta ed eseguono una simulazione dell'esecuzione di uno smart contract (funzione chaincode) con questi dati. Uno smart contract è la logica aziendale di una transazione, un certo insieme di condizioni e istruzioni (nel nostro caso, si tratta di un assegno studentesco, è un nuovo studente o è già registrato, controllo dell'età, ecc.). Per eseguire uno smart contract, avrai bisogno anche dei dati di WorldState. Come risultato della simulazione del contratto intelligente sul peer Endorsing, si ottengono due set di dati: set di lettura e set di scrittura. Read Set e Write Set sono i valori originali e nuovi di WorldState. (nuovo - nel senso ottenuto simulando uno smart contract).
Figura 3. Esecuzione smart contract
3) Restituzione dei dati all'applicazione client
Dopo la simulazione dello smart contract, gli Endorsing Peer restituiscono all'applicazione client i dati iniziali e il risultato della simulazione, nonché l'RW Set firmato dal proprio certificato. In questa fase, non ci sono cambiamenti nel libro mastro distribuito. L'applicazione client verifica la firma dell'Endorsing Peer e confronta anche i dati della transazione originale inviati e i dati restituiti (ovvero controlla se i dati originali su cui è stata simulata la transazione sono stati danneggiati). Se la transazione riguardava solo la lettura dei dati dal registro, l'applicazione client riceve di conseguenza il set di lettura necessario e in questo caso la transazione di solito viene completata correttamente senza modificare il registro distribuito. Nel caso di una transazione che dovrebbe modificare i dati nel registro, l'applicazione client verifica inoltre se è stata implementata la politica di convalida. È possibile che l'applicazione client non verifichi l'esito dell'esecuzione della Endorsement Policy, ma la piattaforma Hyperledger Fabric in questo caso provvede a verificare le policy sui nodi (Committing Peers) in fase di aggiunta di una transazione al registro.
Figura 4. Restituzione dei dati all'applicazione client
4) Invio di set RW a peer di ordinazione
L'applicazione client invia la transazione insieme ai dati correlati al servizio di ordinazione. Ciò include il set RW, le firme dei peer di approvazione e l'ID canale.
Servizio di ordinazione: in base al nome, la funzione principale di questo servizio è creare transazioni in entrata nell'ordine corretto. Nonché la formazione di un nuovo blocco del registro distribuito e la consegna garantita dei nuovi blocchi generati a tutti i nodi di Commiting, garantendo così la coerenza dei dati su tutti i nodi che contengono il registro distribuito (peer di commit). Allo stesso tempo, il servizio di ordinazione stesso non modifica in alcun modo il registro. Il servizio di ordinazione è un componente vitale del sistema, quindi è un cluster di diversi nodi. Il servizio di ordinazione non verifica la validità della transazione, accetta semplicemente una transazione con un ID di canale specifico, organizza le transazioni in entrata in un ordine specifico e da esse forma nuovi blocchi del libro mastro distribuito. Un servizio di ordinazione può servire più canali contemporaneamente. Il servizio di ordinazione include un cluster Kafka, che mantiene la coda delle transazioni corretta (invariata) (vedi punto 7).
Figura 5. Invio di set RW a peer di ordinazione
5) Invio dei blocchi generati al Commiting Peer
I blocchi formati nel servizio di ordinazione vengono trasmessi a tutti i nodi della rete. Ogni nodo, ricevuto un nuovo blocco, ne controlla la conformità alla Politica di Endorsing, controlla che tutti gli Endorsing Peer abbiano ricevuto lo stesso risultato (Write Set) come risultato della simulazione dello smart contract, e controlla anche se i valori originali hanno modificato (ovvero, - Set di lettura - dati letti dallo smart contract da WorldState) dall'inizio della transazione. Se tutte le condizioni sono soddisfatte, la transazione viene contrassegnata come valida, altrimenti la transazione riceve lo stato di non valido.
Figura 6. Invio di blocchi generati al Commiting Peer
6) Aggiunta di un blocco al registro
Ogni nodo aggiunge una transazione alla sua copia locale del libro mastro distribuito e, se la transazione è valida, viene applicato Write Set a WorldState (stato corrente), rispettivamente, vengono scritti nuovi valori degli oggetti interessati dalla transazione . Se una transazione ha ricevuto un token non valido (ad esempio, c'erano due transazioni con gli stessi oggetti all'interno dello stesso blocco, allora una delle transazioni non sarà valida, poiché i valori originali sono già stati modificati da un'altra transazione ). Anche questa transazione viene aggiunta al libro mastro distribuito con un contrassegno non valido, ma il set di scrittura di questa transazione non si applica allo stato corrente del WorldState e, di conseguenza, non modifica gli oggetti che partecipano alla transazione. Successivamente, viene inviata una notifica all'applicazione utente che la transazione è stata aggiunta per sempre al libro mastro distribuito, nonché lo stato della transazione, ovvero se è valida o meno ...
Figura 7. Aggiunta di un blocco al registro
SERVIZIO ORDINI
Il servizio di ordinazione è costituito da un cluster Kafka con i corrispondenti nodi ZooKeeper e un nodo del servizio di ordinazione (OSN) che si trova tra i client del servizio di ordinazione e il cluster Kafka. Il cluster Kafka è una piattaforma di gestione del flusso (messaggi) distribuita e tollerante ai guasti. Ogni canale (argomento) in Kafka è una sequenza immutabile di record che supporta solo l'aggiunta di un nuovo record (non è possibile eliminarne uno esistente). Di seguito viene fornita un'illustrazione della struttura dell'argomento. È questa proprietà di Kafka che viene utilizzata per costruire la piattaforma blockchain.
tratto da kafka.apache.org
- Immagine 8. Struttura dell'argomento del servizio di ordinazione*
Link utili
Ringraziamenti
Esprimo la mia profonda gratitudine ai miei colleghi per il loro aiuto nella preparazione dell'articolo:
Nicolai Marina
Igor Khapov
Dmitry Gorbaciov
Alexander Zemtsov
Ekaterina Guseva
Fonte: habr.com