O platformă Blockchain pentru întreprinderi
Bună ziua, dragi cititori, mă numesc Nikolay Nefedov, sunt specialist tehnic la IBM, în acest articol aș dori să vă prezint platforma blockchain - Hyperledger Fabric. Platforma este concepută pentru a construi aplicații de afaceri de clasă enterprise. Nivelul articolului este pentru cititorii nepregătiți cu cunoștințe de bază despre tehnologiile IT.
Hyperledger Fabric este un proiect open source, una dintre ramurile proiectului open source Hyperledger, un consorțiu al Fundației Linux. Hyperledger Fabric a fost lansat inițial de Digital Assets și IBM. Caracteristica principală a platformei Hyperledger Fabric este concentrarea pe utilizarea întreprinderii. Prin urmare, platforma a fost dezvoltată ținând cont de viteza mare a tranzacțiilor și costul redus al acestora, precum și de identificarea tuturor participanților. Aceste avantaje sunt obținute prin separarea serviciului de verificare a tranzacțiilor și formarea de noi blocuri ale registrului distribuit, precum și prin utilizarea unui centru de certificare și autorizarea participanților.
Articolul meu face parte dintr-o serie de articole despre Hyperledger Fabric, în cadrul cărora descriem un proiect de sistem pentru înregistrarea studenților care intră într-o universitate.
Arhitectura generală a Hyperledger Fabric
Hyperledger Fabric este o rețea blockchain distribuită constând din diverse componente funcționale care sunt instalate pe nodurile rețelei. Componentele Hyperledger Fabric sunt containere Docker care pot fi descărcate gratuit din DockerHub. Hyperledger Fabric poate fi rulat și într-un mediu Kubernetes.
Pentru a scrie contracte inteligente (cod de lanț în contextul Hyperledger Fabric), am folosit Golang (deși Hyperledger Fabric permite utilizarea altor limbi). Pentru a dezvolta o aplicație personalizată, în cazul nostru, am folosit Node.js cu SDK-ul Hyperledger Fabric corespunzător.
Nodurile execută logica de afaceri (contract inteligent) - cod de lanț, stochează starea registrului distribuit (date registrului) și execută alte servicii de sistem ale platformei. Un nod este doar o unitate logică; pe același server fizic pot exista noduri diferite. Mult mai important este modul în care sunt grupate nodurile (domeniul de încredere) și cu ce funcții ale rețelei blockchain sunt asociate.
Arhitectura generală arată astfel:
Imaginea 1. Arhitectura generală a țesăturii Hyperledger
Aplicația utilizator (Submitting Client) este o aplicație cu care utilizatorii lucrează cu rețeaua blockchain. Pentru a lucra, trebuie să fii autorizat și să ai drepturile corespunzătoare pentru diferite tipuri de acțiuni în rețea.
Semenii au mai multe roluri:
- Endorsing Peer este un nod care simulează execuția unei tranzacții (execută codul smart contract). După verificarea și executarea contractului inteligent, nodul returnează rezultatele execuției aplicației client împreună cu semnătura acesteia.
- Serviciul de Comandă este un serviciu distribuit pe mai multe noduri, folosit pentru a genera noi blocuri ale registrului distribuit și pentru a crea o secvență pentru executarea tranzacțiilor. Serviciul de comandă nu adaugă blocuri noi în registru (Această caracteristică a fost mutată în Committing Peers pentru a îmbunătăți performanța).
- Committing Peer este un nod care conține un registru distribuit și adaugă blocuri noi la registru (care au fost generate de Serviciul de Comandă). Toate Committing Peers conțin o copie locală a registrului distribuit. Committing Peer verifică toate tranzacțiile din bloc înainte de a adăuga un nou bloc la nivel local.
Politica de aprobare este politica de verificare a validității unei tranzacții. Aceste politici definesc setul necesar de noduri pe care trebuie să fie executat contractul inteligent pentru ca tranzacția să fie recunoscută ca fiind valabilă.
Registrul distribuit - Lerger - constă din două părți: WolrldState (numit și State DataBase) și BlockChain.
BlockChain este un lanț de blocuri care stochează înregistrările tuturor modificărilor care au avut loc asupra obiectelor de registru distribuite.
WolrldState este o componentă de registru distribuit care stochează valorile curente (de vârf) ale tuturor obiectelor registrului distribuit.
WorldState este o bază de date, în versiunea de bază - LevelDB sau una mai complexă - CouchDB, care conține perechi cheie-valoare, de exemplu: Prenume - Ivan, Nume - Ivanov, data înregistrării în sistem - 12.12.21/17.12.1961/XNUMX , data nașterii - XNUMX etc. WorldState și registrul distribuit trebuie să fie consecvenți între toți participanții la un anumit canal.
Deoarece Hyperledger Fabric este o rețea în care toți participanții sunt cunoscuți și autentificați, folosește o autoritate de certificare dedicată - CA (Autoritatea de certificare). CA funcționează pe baza standardului X.509 și a infrastructurii cu cheie publică - PKI.
Serviciul de membru este un serviciu prin care membrii verifică dacă un obiect aparține unei anumite organizații sau canal.
O tranzacție – în cele mai multe cazuri, este scrierea de date noi într-un registru distribuit.
Există și tranzacții pentru crearea de canale sau contracte inteligente. Tranzacția este inițiată de aplicația utilizator și se încheie cu o înregistrare în registrul distribuit.
Un canal este o subrețea închisă formată din doi sau mai mulți participanți la rețeaua blockchain, concepută pentru a efectua tranzacții confidențiale într-un cerc limitat, dar cunoscut de participanți. Canalul este determinat de participanți, registrul său distribuit, contractele inteligente, Serviciul de comandă, WorldState. Fiecare participant la canal trebuie să fie autorizat să acceseze canalul și să aibă dreptul de a efectua diferite tipuri de tranzacții. Autorizarea se efectuează utilizând Serviciul de membru.
Scenariul tipic de execuție a tranzacțiilor
În continuare, aș dori să vorbesc despre un scenariu tipic de execuție a tranzacțiilor folosind proiectul nostru ca exemplu.
Ca parte a proiectului nostru intern, am creat rețeaua Hyperledger Fabric, care este concepută să înregistreze și să contabilizeze studenții care intră în universități. Rețeaua noastră este formată din două organizații aparținând Universității A și Universității B. Fiecare organizație conține o aplicație client, precum și propriul său Committing and Endorsing Peer. De asemenea, folosim serviciile comune Serviciul de comandă, Serviciul de membru și Autoritatea de certificare.
1) Inițierea tranzacției
O aplicație de utilizator, care utilizează Hyperledger Fabric SDK, inițiază o cerere de tranzacție și trimite cererea către nodurile cu contracte inteligente. Solicitarea poate fi modificarea sau citirea dintr-un registru distribuit (Ledger). Dacă luăm în considerare un exemplu de configurare a sistemului nostru de testare pentru contabilitate pentru studenți, aplicația client trimite o cerere de tranzacție către nodurile universităților A și B, care sunt incluse în politica de aprobare a numitului smart contract. Nodul A este un nod care se află la universitatea care înregistrează studentul care vine, iar nodul B este un nod care este situat la o altă universitate. Pentru ca o tranzacție să fie salvată într-un registru distribuit, este necesar ca toate nodurile care, conform logicii de business, trebuie să aprobe tranzacția, să execute cu succes contracte inteligente cu același rezultat. Aplicația utilizator nodul A, folosind instrumentele Hyperledger Fabric SDK, obține politica de aprobare și învață la ce noduri să trimită o cerere de tranzacție. Aceasta este o solicitare de a invoca un anumit contract inteligent (funcție de cod de lanț) pentru a citi sau scrie anumite date într-un registru distribuit. Din punct de vedere tehnic, SDK-ul client folosește funcția corespunzătoare, căreia API îi este transmis un anumit obiect cu parametrii de tranzacție și, de asemenea, adaugă o semnătură client și trimite aceste date prin intermediul tamponului de protocol prin gRPC la nodurile corespunzătoare (peers de aprobare).
Imaginea 2. Inițierea unei tranzacții
2) Executarea contractului inteligent
Nodurile (Endorsing Peers), după ce au primit o solicitare de a efectua o tranzacție, verifică semnătura clientului și, dacă totul este în ordine, iau un obiect cu datele cererii și rulează o simulare a execuției unui contract inteligent (funcția de cod de lanț) cu aceste date. Un contract inteligent este logica de afaceri a unei tranzacții, un anumit set de condiții și instrucțiuni (în cazul nostru, aceasta este verificarea unui student, acesta este un student nou, sau este deja înregistrat, verificarea vârstei etc.). Pentru a executa contractul inteligent, veți avea nevoie și de date de la WorldState. Ca rezultat al simulării unui contract inteligent pe endorsing peer, se obțin două seturi de date – Read Set și Write Set. Set de citire și set de scriere sunt valorile WorldState originale și noi. (nou – în sensul obținut în timpul simulării unui smart contract).
Imaginea 3. Executarea unui contract inteligent
3) Returnarea datelor către aplicația client
După efectuarea unei simulări a contractului inteligent, Endorsing Peers returnează datele originale și rezultatul simulării, precum și setul RW, semnat prin certificatul lor către aplicația client. În această etapă, nu au loc modificări în registrul distribuit. Aplicația client verifică semnătura Endorsing Peer și, de asemenea, compară datele tranzacției originale care au fost trimise și datele care au fost returnate (adică verifică dacă datele originale pe care a fost simulată tranzacția au fost distorsionate). Dacă tranzacția a fost doar pentru citirea datelor din registru, atunci aplicația client primește în consecință setul de citire necesar și, de obicei, aceasta finalizează tranzacția cu succes fără a schimba registrul distribuit. În cazul unei tranzacții care trebuie să modifice datele din registru, aplicația client verifică suplimentar implementarea politicii de Endorsing. Este posibil ca o aplicație client să nu verifice rezultatul executării Politicii de aprobare, dar platforma Hyperledger Fabric prevede în acest caz verificarea politicilor pe noduri (Committing Peers) în etapa de adăugare a unei tranzacții în registru.
Imaginea 4. Returnarea datelor către aplicația client
4) Trimiterea de seturi RW către Ordering Peers
Aplicația client trimite tranzacția împreună cu datele însoțitoare către serviciul de comandă. Aceasta include setul RW, semnăturile de susținere a colegilor și ID-ul canalului.
Serviciul de comandă – pe baza numelui, funcția principală a acestui serviciu este de a aranja tranzacțiile primite în ordinea corectă. Precum și formarea unui nou bloc al registrului distribuit și livrarea garantată a noilor blocuri generate către toate nodurile Commiting, asigurând astfel consistența datelor pe toate nodurile care conțin registrul distribuit (Committing peers). În același timp, serviciul de Comandă în sine nu modifică în niciun fel registrul. Serviciul de comandă este o componentă vitală a sistemului, deci este un grup de mai multe noduri. Serviciul de comenzi nu verifică valabilitatea tranzacției, pur și simplu acceptă o tranzacție cu un anumit identificator de canal, aranjează tranzacțiile primite într-o anumită ordine și formează noi blocuri ale registrului distribuit din acestea. Un serviciu de comandă poate deservi mai multe canale simultan. Serviciul de Comandă include un cluster Kafka, care menține coada de tranzacții corectă (imuabilă) (vezi Punctul 7).
Imaginea 5. Trimiterea seturilor RW către Ordering Peers
5) Trimiterea blocurilor generate către Committing Peer
Blocurile generate în Serviciul de Comandă sunt transmise (difuzate) către toate nodurile rețelei. Fiecare nod, după ce a primit un nou bloc, îl verifică pentru conformitatea cu Politica de aprobare, verifică dacă toți Endorsing Peers au primit același rezultat (Set de scriere) ca urmare a simulării contractului inteligent și, de asemenea, verifică dacă valorile originale au schimbat (adică Read Set - date citite de contractul inteligent de la WorldState) din momentul inițierii tranzacției. Dacă sunt îndeplinite toate condițiile, tranzacția este marcată ca validă, în caz contrar, tranzacția primește statutul invalid.
Imaginea 6. Trimiterea blocurilor generate către Committing Peer
6) Adăugarea unui bloc la registru
Fiecare nod adaugă o tranzacție la copia sa locală a registrului distribuit, iar dacă tranzacția este validă, atunci setul de scriere este aplicat la WorldState (starea curentă) și, în consecință, noile valori ale obiectelor care au fost afectate de tranzacția sunt scrise. Dacă o tranzacție a primit un simbol care nu este valid (de exemplu, două tranzacții au avut loc cu aceleași obiecte în cadrul aceluiași bloc, atunci una dintre tranzacții se va dovedi a fi nevalidă, deoarece valorile originale au fost deja modificate de către altul tranzacţie). Această tranzacție este, de asemenea, adăugată la registrul distribuit cu un token invalid, dar setul de scriere al acestei tranzacții nu este aplicat la WorldState actual și, în consecință, nu modifică obiectele care participă la tranzacție. După aceasta, se trimite aplicației utilizator o notificare că tranzacția a fost adăugată permanent în registrul distribuit, precum și starea tranzacției, adică dacă este valabilă sau nu...
Imaginea 7. Adăugarea unui bloc la registry
SERVICIUL COMANDI
Serviciul de comandă constă dintr-un cluster Kafka cu noduri ZooKeeper corespunzătoare și noduri de servicii de comandă (OSN), care stau între clienții serviciului de comandă și clusterul Kafka. Clusterul Kafka este o platformă de gestionare a fluxului (mesajelor) distribuită, tolerantă la erori. Fiecare canal (subiect) din Kafka este o secvență imuabilă de înregistrări care acceptă doar adăugarea unei noi înregistrări (ștergerea uneia existente nu este posibilă). O ilustrare a structurii subiectului este prezentată mai jos. Această proprietate a lui Kafka este folosită pentru a construi o platformă blockchain.
preluat de pe kafka.apache.org
- Imaginea 8. Structura subiectului serviciului de comandă*
Link-uri utile
Mulțumiri
Aș dori să-mi exprim profunda recunoștință colegilor mei pentru ajutorul acordat în pregătirea acestui articol:
Nikolay Marin
Igor Khapov
Dmitri Gorbaciov
Alexandru Zemțov
Ekaterina Guseva
Sursa: www.habr.com