Una plataforma Blockchain per a l'empresa
Bona tarda, estimats lectors, em dic Nikolay Nefedov, sóc un especialista tècnic d'IBM, en aquest article m'agradaria presentar-vos la plataforma blockchain - Hyperledger Fabric. La plataforma està dissenyada per crear aplicacions empresarials de classe empresarial. El nivell de l'article és per a lectors no preparats amb coneixements bàsics de tecnologies de TI.
Hyperledger Fabric és un projecte de codi obert, una de les branques del projecte Hyperledger de codi obert, un consorci de la Fundació Linux. Hyperledger Fabric va ser iniciat originalment per Digital Assets i IBM. La característica principal de la plataforma Hyperledger Fabric és el seu enfocament en l'ús empresarial. Per tant, la plataforma s'ha desenvolupat tenint en compte l'alta velocitat de les transaccions i el seu baix cost, així com la identificació de tots els participants. Aquests avantatges s'aconsegueixen mitjançant la separació del servei de verificació de transaccions i la formació de nous blocs del registre distribuït, així com l'ús d'un centre de certificació i autorització dels participants.
El meu article forma part d'una sèrie d'articles sobre Hyperledger Fabric, dins dels quals descrivim un projecte de sistema per registrar els estudiants que ingressen a una universitat.
Arquitectura general d'Hyperledger Fabric
Hyperledger Fabric és una xarxa de cadena de blocs distribuïda que consta de diversos components funcionals que s'instal·len als nodes de la xarxa. Els components d'Hyperledger Fabric són contenidors Docker que es poden descarregar gratuïtament des de DockerHub. Hyperledger Fabric també es pot executar en un entorn Kubernetes.
Per escriure contractes intel·ligents (codi de cadena en el context d'Hyperledger Fabric), hem utilitzat Golang (tot i que Hyperledger Fabric permet l'ús d'altres idiomes). Per desenvolupar una aplicació personalitzada, en el nostre cas, hem utilitzat Node.js amb el corresponent SDK d'Hyperledger Fabric.
Els nodes executen la lògica empresarial (contracte intel·ligent): codi de cadena, emmagatzemen l'estat del registre distribuït (dades del llibre major) i executen altres serveis del sistema de la plataforma. Un node és només una unitat lògica; poden existir diferents nodes al mateix servidor físic. Molt més important és com s'agrupen els nodes (domini de confiança) i a quines funcions de la xarxa blockchain estan associats.
L'arquitectura general és així:
Imatge 1. Arquitectura general de Hyperledger Fabric
L'aplicació d'usuari (Submitting Client) és una aplicació amb la qual els usuaris treballen amb la xarxa blockchain. Per treballar, has d'estar autoritzat i tenir els drets adequats per a diferents tipus d'accions a la xarxa.
Els companys tenen diversos rols:
- Endorsing Peer és un node que simula l'execució d'una transacció (executa el codi de contracte intel·ligent). Després de la verificació i l'execució del contracte intel·ligent, el node retorna els resultats de l'execució a l'aplicació client juntament amb la seva signatura.
- El servei de comandes és un servei distribuït en diversos nodes, utilitzat per generar nous blocs del registre distribuït i crear una cua per a l'execució de transaccions. El servei de comandes no afegeix blocs nous al registre (aquesta característica s'ha mogut a Committing Peers per millorar el rendiment).
- Committing Peer és un node que conté un registre distribuït i que afegeix nous blocs al registre (que van ser generats pel servei de comandes). Tots els Committing Peers contenen una còpia local del llibre major distribuït. Committing Peer comprova la validesa de totes les transaccions del bloc abans d'afegir un nou bloc localment.
La política d'aprovació és la política per comprovar la validesa d'una transacció. Aquestes polítiques defineixen el conjunt necessari de nodes en què s'ha d'executar el contracte intel·ligent perquè la transacció sigui reconeguda com a vàlida.
El registre distribuït - Lerger - consta de dues parts: WolrldState (també anomenat State DataBase) i BlockChain.
BlockChain és una cadena de blocs que emmagatzema registres de tots els canvis que s'han produït als objectes de registre distribuïts.
WolrldState és un component de registre distribuït que emmagatzema els valors actuals (avantguarda) de tots els objectes de registre distribuïts.
WorldState és una base de dades, en la versió bàsica - LevelDB o una de més complexa - CouchDB, que conté parells clau-valor, per exemple: Nom - Ivan, Cognom - Ivanov, data de registre al sistema - 12.12.21/17.12.1961/XNUMX , data de naixement - XNUMX/XNUMX/XNUMX, etc. WorldState i el registre distribuït han de ser coherents entre tots els participants d'un canal determinat.
Com que Hyperledger Fabric és una xarxa en què tots els participants són coneguts i autenticats, utilitza una autoritat de certificació dedicada: CA (Autoritat de certificació). CA funciona segons l'estàndard X.509 i la infraestructura de clau pública - PKI.
El servei de membres és un servei mitjançant el qual els membres verifiquen que un objecte pertany a una organització o canal en particular.
Una transacció, en la majoria dels casos, és escriure dades noves en un registre distribuït.
També hi ha transaccions per a la creació de canals o contractes intel·ligents. La transacció l'inicia l'aplicació d'usuari i acaba amb un registre al llibre major distribuït.
Un canal és una subxarxa tancada formada per dos o més participants de la xarxa blockchain, dissenyada per dur a terme transaccions confidencials dins d'un cercle limitat però conegut de participants. El canal el determinen els participants, el seu registre distribuït, contractes intel·ligents, servei de comandes, WorldState. Cada participant del canal ha d'estar autoritzat per accedir al canal i tenir dret a realitzar diferents tipus de transaccions. L'autorització es realitza mitjançant el Servei de Membres.
Escenari típic d'execució de transaccions
A continuació, m'agradaria parlar d'un escenari típic d'execució de transaccions utilitzant el nostre projecte com a exemple.
Com a part del nostre projecte intern, vam crear la xarxa Hyperledger Fabric, que està dissenyada per registrar i comptabilitzar els estudiants que ingressen a les universitats. La nostra xarxa està formada per dues organitzacions que pertanyen a la Universitat A i la Universitat B. Cada organització conté una aplicació client, així com la seva pròpia Committing and Endorsing Peer. També fem servir els serveis comuns Servei de comandes, Servei de membres i Autoritat de certificació.
1) Iniciació de la transacció
Una aplicació d'usuari, que utilitza l'SDK de Hyperledger Fabric, inicia una sol·licitud de transacció i envia la sol·licitud als nodes amb contractes intel·ligents. La sol·licitud pot ser canviar o llegir des d'un registre distribuït (Ledger). Si considerem un exemple de la configuració del nostre sistema de prova per a la comptabilitat d'estudiants universitaris, l'aplicació client envia una sol·licitud de transacció als nodes de les universitats A i B, que s'inclouen a la política d'aprovació de l'anomenat contracte intel·ligent. El node A és un node que es troba a la universitat que registra l'estudiant entrant, i el node B és un node que es troba a una altra universitat. Perquè una transacció es desi en un registre distribuït, és necessari que tots els nodes que, segons la lògica empresarial, han d'aprovar la transacció, executin amb èxit contractes intel·ligents amb el mateix resultat. L'aplicació d'usuari del node A, utilitzant les eines Hyperledger Fabric SDK, obté la política d'aprovació i aprèn a quins nodes ha d'enviar una sol·licitud de transacció. Aquesta és una sol·licitud per invocar un contracte intel·ligent específic (funció de codi de cadena) per llegir o escriure determinades dades en un registre distribuït. Tècnicament, l'SDK del client utilitza la funció corresponent, a l'API de la qual se li passa un determinat objecte amb paràmetres de transacció, i també afegeix una signatura del client i envia aquestes dades mitjançant un buffer de protocol a través de gRPC als nodes adequats (peers d'aprovació).
Imatge 2. Iniciant una transacció
2) Execució de contracte intel·ligent
Els nodes (Endorsing Peers), després d'haver rebut una sol·licitud per dur a terme una transacció, comproven la signatura del client i si tot està en ordre, prenen un objecte amb les dades de la sol·licitud i executen una simulació de l'execució d'un contracte intel·ligent (funció de codi de cadena) amb aquestes dades. Un contracte intel·ligent és la lògica empresarial d'una transacció, un determinat conjunt de condicions i instruccions (en el nostre cas, es tracta de la verificació d'un estudiant, és un estudiant nou o ja està registrat, verificació d'edat, etc.). Per executar el contracte intel·ligent, també necessitareu dades de WorldState. Com a resultat de la simulació d'un contracte intel·ligent al parell d'aprovació, s'obtenen dos conjunts de dades: conjunt de lectura i conjunt d'escriptura. Read Set i Write Set són els valors originals i nous de WorldState. (nou, en el sentit obtingut durant la simulació d'un contracte intel·ligent).
Imatge 3. Execució d'un contracte intel·ligent
3) Devolució de dades a l'aplicació client
Després de realitzar una simulació del contracte intel·ligent, Endorsing Peers retorna les dades originals i el resultat de la simulació, així com el conjunt RW, signat pel seu certificat a l'aplicació client. En aquesta etapa, no es produeixen canvis al registre distribuït. L'aplicació client comprova la signatura Endorsing Peer i també compara les dades de transacció originals que es van enviar i les dades que es van retornar (és a dir, comprova si les dades originals sobre les quals es va simular la transacció s'han distorsionat). Si la transacció només va ser per llegir dades del registre, aleshores l'aplicació client rep el conjunt de lectura necessari i això normalment completa la transacció amb èxit sense canviar el registre distribuït. En el cas d'una transacció que ha de canviar les dades del registre, l'aplicació client comprova, a més, la implementació de la política d'aprovació. És possible que una aplicació de client no comprovi el resultat de l'execució de la política d'aprovació, però la plataforma Hyperledger Fabric en aquest cas proporciona la comprovació de polítiques als nodes (committing peers) en l'etapa d'afegir una transacció al registre.
Imatge 4. Devolució de dades a l'aplicació client
4) Enviament de conjunts RW als iguals d'ordenació
L'aplicació client envia la transacció juntament amb les dades que l'acompanyen al servei de comandes. Això inclou el conjunt RW, les signatures d'endorsing peers i l'identificador del canal.
Servei de comandes: segons el nom, la funció principal d'aquest servei és organitzar les transaccions entrants en l'ordre correcte. Així com la formació d'un nou bloc del registre distribuït i el lliurament garantit de nous blocs generats a tots els nodes de Committing, garantint així la coherència de les dades en tots els nodes que contenen el registre distribuït (committing peers). Al mateix temps, el propi servei de Comandes no modifica el registre de cap manera. El servei de comandes és un component vital del sistema, de manera que és un clúster de diversos nodes. El Servei de Comandes no verifica la validesa de la transacció, simplement accepta una transacció amb un determinat identificador de canal, organitza les transaccions entrants en un ordre determinat i forma nous blocs del registre distribuït a partir d'ells. Un servei de comandes pot servir diversos canals simultàniament. El servei de comandes inclou un clúster de Kafka, que manté la cua de transaccions correcta (immutable) (vegeu el punt 7).
Imatge 5. Enviament de conjunts RW a Ordering Peers
5) Enviament de blocs generats a Committing Peer
Els blocs generats al Servei de Comandes es transmeten (difusió) a tots els nodes de la xarxa. Cada node, després d'haver rebut un bloc nou, comprova que compleixi amb la política d'aprovació, comprova que tots els pares d'aprovació han rebut el mateix resultat (conjunt d'escriptura) com a resultat de la simulació de contracte intel·ligent i també comprova si els valors originals tenen canviat (és a dir, Read Set - dades llegides pel contracte intel·ligent de WorldState) des del moment en què es va iniciar la transacció. Si es compleixen totes les condicions, la transacció es marcarà com a vàlida; en cas contrari, la transacció rebrà l'estat de no vàlida.
Imatge 6. Enviament de blocs generats a Committing Peer
6) Afegir un bloc al registre
Cada node afegeix una transacció a la seva còpia local del registre distribuït i, si la transacció és vàlida, el conjunt d'escriptura s'aplica al WorldState (estat actual) i, en conseqüència, nous valors dels objectes afectats pel transacció estan escrites. Si una transacció va rebre un testimoni que no és vàlid (per exemple, dues transaccions es van produir amb els mateixos objectes dins del mateix bloc, llavors una de les transaccions resultarà no vàlida, ja que els valors originals ja han estat modificats per un altre). transacció). Aquesta transacció també s'afegeix al llibre major distribuït amb un testimoni no vàlid, però el conjunt d'escriptura d'aquesta transacció no s'aplica al WorldState actual i, en conseqüència, no canvia els objectes que participen en la transacció. Després d'això, s'envia una notificació a l'aplicació d'usuari que la transacció s'ha afegit de manera permanent al registre distribuït, així com l'estat de la transacció, és a dir, si és vàlida o no...
Imatge 7. Afegir un bloc al registre
SERVEI DE COMANDES
El servei de comandes consta d'un clúster de Kafka amb els nodes ZooKeeper corresponents i els nodes de servei de comandes (OSN), que es troben entre els clients del servei de comandes i el clúster Kafka. El clúster Kafka és una plataforma de gestió de fluxos (missatges) distribuïda i tolerant a errors. Cada canal (tema) a Kafka és una seqüència immutable de registres que només admet afegir un registre nou (no és possible eliminar-ne un existent). A continuació es mostra una il·lustració de l'estructura del tema. Aquesta propietat de Kafka s'utilitza per construir una plataforma blockchain.
extret de kafka.apache.org
- Imatge 8. Estructura del tema del servei de comandes*
Links útils
Agraïments
M'agradaria expressar el meu profund agraïment als meus companys per la seva ajuda en la preparació d'aquest article:
Nikolai Marín
Igor Khapov
Dmitri Gorbatxov
Alexander Zemtsov
Ekaterina Guseva
Font: www.habr.com