En Blockchain-platform for virksomheden
God eftermiddag, kære læsere, mit navn er Nikolai Nefedov, jeg er en IBM teknisk specialist, i denne artikel vil jeg gerne introducere dig til blockchain-platformen - Hyperledger Fabric. Platformen er beregnet til opbygning af forretningsapplikationer på virksomhedsniveau (Enterprise-klassen). Artiklens niveau er for uforberedte læsere med grundlæggende viden om it-teknologier.
Hyperledger Fabric er et open source-projekt, en af grenene af Hyperledger open source-projektet, et konsortium af Linux Foundation. Hyperledger Fabric blev oprindeligt lanceret af Digital Assets og IBM. Hovedegenskaben ved Hyperledger Fabric-platformen er dens fokus på virksomhedsapplikationer. Derfor blev platformen udviklet under hensyntagen til den høje hastighed af transaktioner og deres lave omkostninger, samt identifikation af alle deltagere. Disse fordele opnås ved at adskille transaktionsbekræftelsestjenesten og danne nye blokke af det distribuerede register, samt bruge en certifikatmyndighed og autorisere deltagere.
Min artikel er en del af en serie artikler om Hyperledger Fabric, hvori vi beskriver projektet med et system til registrering af studerende, der kommer ind på et universitet.
Generel arkitektur af Hyperledger Fabric
Hyperledger Fabric er et distribueret blockchain-netværk, der består af forskellige funktionelle komponenter, der er installeret på netværksknuder. Hyperledger Fabric-komponenter er Docker-containere, der frit kan downloades fra DockerHub. Hyperledger Fabric kan også køres i et Kubernetes-miljø.
Til at skrive smarte kontrakter (kædekode i sammenhæng med Hyperledger Fabric) brugte vi Golang (selvom Hyperledger Fabric giver dig mulighed for at bruge andre sprog). For at udvikle en brugerdefineret applikation blev Node.js i vores tilfælde brugt med det tilsvarende Hyperledger Fabric SDK.
Noderne kører forretningslogik (smart kontrakt) - kædekode, gemmer tilstanden af det distribuerede register (ledger data) og udfører andre platformsystemtjenester. En node er kun en logisk enhed, forskellige noder kan eksistere på den samme fysiske server. Meget vigtigere er, hvordan noderne er grupperet (Trusted domain), og hvilke funktioner i blockchain-netværket de er forbundet med.
Den generelle arkitektur ser således ud:
Billede 1. Generel arkitektur af Hyperledger-stof
Brugerapplikation (Submitting Client) er en applikation, som brugere arbejder med blockchain-netværket med. For at arbejde skal du gennemgå autorisation og have de nødvendige rettigheder til forskellige former for handlinger på netværket.
Peers (knudepunkter) kommer i flere roller:
- Endoring Peer er en node, der simulerer udførelsen af en transaktion (udfører den smarte kontraktkode). Efter validering og eksekvering af den smarte kontrakt returnerer noden udførelsesresultaterne til klientapplikationen sammen med sin signatur.
- Ordreservice er en distribueret service på flere noder, den bruges til at danne nye blokke af den distribuerede hovedbog og skabe en sekvens til udførelse af transaktioner. Bestillingstjeneste tilføjer ikke nye blokke til registreringsdatabasen (flyttet til Committing Peers for bedre ydeevne).
- Committing Peer - en node, der indeholder et distribueret register og tilføjer nye blokke til registreringsdatabasen (som blev dannet af bestillingstjenesten). Alle Committing Peers indeholder en lokal kopi af den distribuerede hovedbog. Den Committing Peer kontrollerer, før den tilføjer en ny blok lokalt, alle transaktioner inden for blokken for gyldighed.
Godkendelsespolitik er en politik til kontrol af en transaktions gyldighed. Disse politikker definerer det nødvendige sæt af noder, som den smarte kontrakt skal udføres på, for at transaktionen kan anerkendes som gyldig.
Det distribuerede register - Lerger - består af to dele: WolrldState (også kaldet State DataBase) og BlockChain.
BlockChain er en kæde af blokke, der gemmer registreringer af alle ændringer, der er sket på distribuerede hovedbogsobjekter.
WolrldState er en distribueret registreringsdatabasekomponent, der gemmer de aktuelle (ekstrem) værdier af alle distribuerede registreringsobjekter.
WorldState er en database, i grundversionen - LevelDB eller mere kompleks - CouchDB, som indeholder nøgle-værdi-par, for eksempel: Fornavn - Ivan, Efternavn - Ivanov, registreringsdato i systemet - 12.12.21/17.12.1961/XNUMX, dato pr. fødsel - XNUMX mv. WorldState og den distribuerede hovedbog skal være konsistente på tværs af alle medlemmer af en given kanal.
Da Hyperledger Fabric er et netværk, hvor alle deltagere er kendte og autentificerede, bruges her en dedikeret certificeringsmyndighed - CA (Certification Authority). CA opererer på basis af X.509-standarden og offentlig nøgleinfrastruktur - PKI.
Medlemsservice er en tjeneste, hvorigennem medlemmer bekræfter, at et objekt tilhører en bestemt organisation eller kanal.
En transaktion er i de fleste tilfælde en registrering af nye data i en distribueret hovedbog.
Der er også transaktioner til oprettelse af kanaler eller smarte kontrakter. Transaktionen initieres af brugerapplikationen og afsluttes med en skrivning til den distribuerede hovedbog.
Channel (Channel) er et lukket undernet bestående af to eller flere deltagere i blockchain-netværket, designet til at udføre fortrolige transaktioner inden for en begrænset, men kendt kreds af deltagere. Kanalen bestemmes af deltagerne, dens distribuerede hovedbog, smarte kontrakter, bestillingsservice, WorldState. Hvert kanalmedlem skal have tilladelse til at få adgang til kanalen og have ret til at udføre forskellige former for transaktioner. Autorisation udføres ved hjælp af Medlemsservice.
Typisk transaktionsudførelsesscenarie
Dernæst vil jeg gerne tale om et typisk scenarie for at udføre en transaktion ved at bruge eksemplet med vores projekt.
Som en del af vores interne projekt har vi oprettet et Hyperledger Fabric-netværk, som er designet til at registrere og registrere studerende, der kommer ind på universiteter. Vores netværk består af to organisationer, der ejes af Universitet A og Universitet B. Hver organisation indeholder en klientapplikation samt sin egen Committing and Endorsing Peer. Vi bruger også den fælles bestillingsservice, medlemsservice og certificeringsmyndighedstjenester.
1) Transaktionsinitiering
Brugerapplikationen ved hjælp af Hyperledger Fabric SDK starter en transaktionsanmodning og sender anmodningen til noder med smarte kontrakter. Anmodningen kan være at ændre eller læse fra en distribueret hovedbog (Ledger). Hvis vi betragter et eksempel på vores testkonfiguration af systemet til regnskabsføring for universitetsstuderende, sender klientapplikationen en transaktionsanmodning til noderne på universiteterne A og B, som er inkluderet i godkendelsespolitikken for den kaldede smarte kontrakt. Node A er en node, der er placeret på universitetet, der registrerer en indkommende studerende, og node B er en node, der er placeret på et andet universitet. For at en transaktion kan gemmes i en distribueret hovedbog, er det nødvendigt, at alle noder, der ifølge forretningslogikken skal godkende transaktionen, gennemfører smarte kontrakter med samme resultat. Brugerapplikationen af node A, ved hjælp af Hyperledger Fabric SDK-værktøjerne, modtager godkendelsespolitikken (godkendelsespolitik) og finder ud af, hvilke noder der skal sendes en transaktionsanmodning til. Dette er en anmodning om at kalde (påkalde) en bestemt smart kontrakt (kædekodefunktion) for at læse eller skrive bestemte data til den distribuerede hovedbog. Teknisk set bruger klient-SDK'en den tilsvarende funktion, hvis API sendes til et objekt med transaktionsparametre, og tilføjer også en klientsignatur og sender disse data via protokolbuffer over gRPC til de relevante noder (godkender peers).
Billede 2. Transaktionsinitiering
2) Smart kontraktudførelse
Noder (Endoring Peers), efter at have modtaget en anmodning om at udføre en transaktion, kontrollere klientsignaturen, og hvis alt er i orden, tager de et objekt med anmodningsdataene og kører en simulering af udførelsen af en smart kontrakt (kædekodefunktion) med disse data. En smart kontrakt er forretningslogikken i en transaktion, et bestemt sæt betingelser og instruktioner (i vores tilfælde er dette et elevtjek, er det en ny elev, eller er han allerede registreret, alderskontrol osv.). For at udføre en smart kontrakt skal du også bruge data fra WorldState. Som et resultat af den smarte kontraktsimulering på Endorsing-peeren opnås to datasæt - Read Set og Write Set. Read Set og Write Set er de originale og nye WorldState værdier. (nyt - i den forstand opnået ved at simulere en smart kontrakt).
Billede 3. Smart kontraktudførelse
3) Returnering af data til klientapplikationen
Efter simuleringen af den smarte kontrakt returnerer Endorsing Peers til klientapplikationen de indledende data og resultatet af simuleringen samt RW-sættet, der er underskrevet af deres certifikat. På dette tidspunkt er der ingen ændringer i den distribuerede finans. Klientapplikationen verificerer signaturen på den godkendende peer og sammenligner også de oprindelige transaktionsdata, der blev sendt, og de data, der returnerede (det vil sige, den kontrollerer, om de originale data, som transaktionen blev simuleret på, er blevet beskadiget). Hvis transaktionen kun var til læsning af data fra registreringsdatabasen, modtager klientapplikationen følgelig det nødvendige læsesæt, og på dette afsluttes transaktionen normalt uden at ændre det distribuerede register. I tilfælde af en transaktion, der skulle ændre dataene i registreringsdatabasen, kontrollerer klientapplikationen desuden, om godkendelsespolitikken er blevet implementeret. Det er muligt, at klientapplikationen ikke kontrollerer resultatet af udførelse af godkendelsespolitikken, men Hyperledger Fabric-platformen sørger i dette tilfælde for at kontrollere politikkerne på noderne (Committing Peers) på tidspunktet for tilføjelse af en transaktion til registreringsdatabasen.
Billede 4. Returnering af data til klientapplikationen
4) Sender RW-sæt til bestillingsfæller
Klientapplikationen sender transaktionen sammen med relaterede data til bestillingstjenesten. Dette inkluderer RW-sættet, underskrifter fra godkendende peers og kanal-id'et.
Bestillingsservice - Baseret på navnet er denne services hovedfunktion at opbygge indgående transaktioner i den rigtige rækkefølge. Samt dannelsen af en ny blok af det distribuerede register og den garanterede levering af nye genererede blokke til alle Commiting noder, hvilket sikrer datakonsistens på alle noder, der indeholder det distribuerede register (Committing peers). Samtidig ændrer selve Bestillingstjenesten ikke registreringsdatabasen på nogen måde. Bestillingsservice er en vital komponent i systemet, så det er en klynge af flere noder. Bestillingstjenesten kontrollerer ikke transaktionens gyldighed, den accepterer blot en transaktion med et specifikt kanal-id, arrangerer indgående transaktioner i en bestemt ordre og danner nye blokke af den distribuerede hovedbog fra dem. En bestillingsservice kan betjene flere kanaler på samme tid. Bestillingstjenesten inkluderer en Kafka-klynge, som opretholder den korrekte (uændrede) transaktionskø (se punkt 7).
Billede 5. Sender RW-sæt til bestilling af peers
5) Sende de genererede blokke til den Committing Peer
De blokke, der dannes i bestillingstjenesten, udsendes til alle netværksknuder. Hver node, efter at have modtaget en ny blok, tjekker den for overholdelse af godkendelsespolitikken, kontrollerer, at alle godkendende peers modtog det samme resultat (skrivesæt) som et resultat af smart kontraktsimuleringen, og kontrollerer også, om de originale værdier har ændret (det vil sige - Read Set - data læst af den smarte kontrakt fra WorldState) siden initieringen af transaktionen. Hvis alle betingelser er opfyldt, markeres transaktionen som gyldig, ellers får transaktionen status som ikke gyldig.
Billede 6. Sender genererede blokke til Committing Peer
6) Tilføjelse af en blok til registreringsdatabasen
Hver node tilføjer en transaktion til sin lokale kopi af den distribuerede hovedbog, og hvis transaktionen er gyldig, så anvendes Write Set på henholdsvis WorldState (nuværende tilstand), nye værdier af objekter, der blev påvirket af transaktionen, skrives . Hvis en transaktion modtog et token, der ikke var gyldigt (for eksempel var der to transaktioner med de samme objekter inden for samme blok, så vil en af transaktionerne ikke være gyldig, da de oprindelige værdier allerede er blevet ændret af en anden transaktion ). Denne transaktion føjes også til den distribuerede hovedbog med en ugyldig markør, men skrivesættet for denne transaktion gælder ikke for den aktuelle tilstand i WorldState og ændrer følgelig ikke de objekter, der deltager i transaktionen. Derefter sendes en meddelelse til brugerapplikationen om, at transaktionen er blevet tilføjet til den distribuerede hovedbog for altid, samt status for transaktionen, det vil sige om den er gyldig eller ej ...
Billede 7. Tilføjelse af en blok til registreringsdatabasen
BESTILLINGSSERVICE
Bestillingstjenesten består af en Kafka-klynge med tilsvarende ZooKeeper-noder og en bestillingstjenesteknude (OSN), der sidder mellem bestillingstjenestekunderne og Kafka-klyngen. Kafka-klyngen er en distribueret, fejltolerant flow- (meddelelses-) administrationsplatform. Hver kanal (emne) i Kafka er en uforanderlig sekvens af poster, der kun understøtter tilføjelse af en ny post (det er ikke muligt at slette en eksisterende). En illustration af emnestrukturen er givet nedenfor. Det er denne egenskab hos Kafka, der bruges til at bygge blockchain-platformen.
taget fra kafka.apache.org
- Billede 8. Emnestruktur for bestillingsservice*
Nyttige links
Tak
Jeg udtrykker min dybe taknemmelighed til mine kolleger for deres hjælp til at udarbejde artiklen:
Nikolaj Marina
Igor Khapov
Dmitrij Gorbatjov
Alexander Zemtsov
Ekaterina Guseva
Kilde: www.habr.com