En blokkjedeplattform for bedriften
God ettermiddag, kjære lesere, jeg heter Nikolay Nefedov, jeg er teknisk spesialist hos IBM, i denne artikkelen vil jeg gjerne introdusere deg til blockchain-plattformen - Hyperledger Fabric. Plattformen er designet for å bygge forretningsapplikasjoner i bedriftsklassen. Nivået på artikkelen er for uforberedte lesere med grunnleggende kunnskap om IT-teknologier.
Hyperledger Fabric er et åpen kildekode-prosjekt, en av grenene til åpen kildekode Hyperledger-prosjektet, et konsortium av Linux Foundation. Hyperledger Fabric ble opprinnelig startet av Digital Assets og IBM. Hovedfunksjonen til Hyperledger Fabric-plattformen er dens fokus på bedriftsbruk. Derfor ble plattformen utviklet under hensyntagen til den høye hastigheten på transaksjoner og deres lave kostnader, samt identifisering av alle deltakere. Disse fordelene oppnås gjennom separasjon av transaksjonsverifiseringstjenesten og dannelsen av nye blokker av det distribuerte registeret, samt bruk av et sertifiseringssenter og autorisasjon av deltakere.
Artikkelen min er en del av en serie artikler om Hyperledger Fabric, der vi beskriver et systemprosjekt for registrering av studenter som kommer inn på et universitet.
Generell arkitektur av Hyperledger Fabric
Hyperledger Fabric er et distribuert blokkjedenettverk som består av ulike funksjonelle komponenter som er installert på nettverksnoder. Hyperledger Fabric-komponenter er Docker-beholdere som fritt kan lastes ned fra DockerHub. Hyperledger Fabric kan også kjøres i et Kubernetes-miljø.
For å skrive smarte kontrakter (kjedekode i sammenheng med Hyperledger Fabric), brukte vi Golang (selv om Hyperledger Fabric tillater bruk av andre språk). For å utvikle en tilpasset applikasjon, i vårt tilfelle, brukte vi Node.js med den tilsvarende Hyperledger Fabric SDK.
Nodene utfører forretningslogikk (smart kontrakt) - kjedekode, lagrer tilstanden til det distribuerte registeret (reskontrodata) og utfører andre systemtjenester på plattformen. En node er bare en logisk enhet; forskjellige noder kan eksistere på samme fysiske server. Mye viktigere er hvordan nodene er gruppert (Trusted domain) og hvilke funksjoner i blokkjedenettverket de er knyttet til.
Den generelle arkitekturen ser slik ut:
Bilde 1. Generell arkitektur av Hyperledger Fabric
Brukerapplikasjon (Submitting Client) er en applikasjon som brukere arbeider med blokkjedenettverket med. For å jobbe må du være autorisert og ha de nødvendige rettighetene for ulike typer handlinger på nettverket.
Likemenn kommer i flere roller:
- Endorsing Peer er en node som simulerer utførelsen av en transaksjon (utfører den smarte kontraktskoden). Etter verifisering og utførelse av den smarte kontrakten, returnerer noden utførelsesresultatene til klientapplikasjonen sammen med sin signatur.
- Bestillingstjeneste er en distribuert tjeneste på flere noder, som brukes til å generere nye blokker av det distribuerte registeret og opprette en kø for gjennomføring av transaksjoner. Bestillingstjeneste legger ikke til nye blokker til registeret (Denne funksjonen er flyttet til Committing Peers for å forbedre ytelsen).
- Committing Peer er en node som inneholder et distribuert register og legger til nye blokker til registeret (som ble generert av bestillingstjenesten). Alle Committing Peers inneholder en lokal kopi av den distribuerte hovedboken. Committing Peer sjekker alle transaksjoner innenfor blokken for gyldighet før en ny blokk legges til lokalt.
Retningslinjer for godkjenning er retningslinjene for å kontrollere gyldigheten av en transaksjon. Disse retningslinjene definerer det nødvendige settet med noder som den smarte kontrakten må utføres på for at transaksjonen skal bli anerkjent som gyldig.
Det distribuerte registeret - Lerger - består av to deler: WolrldState (også kalt State DataBase) og BlockChain.
BlockChain er en kjede av blokker som lagrer poster over alle endringer som har skjedd i distribuerte registerobjekter.
WolrldState er en distribuert hovedbok-komponent som lagrer gjeldende (nye) verdier for alle distribuerte hovedbokobjekter.
WorldState er en database, i grunnversjonen - LevelDB eller en mer kompleks - CouchDB, som inneholder nøkkelverdi-par, for eksempel: Fornavn - Ivan, Etternavn - Ivanov, registreringsdato i systemet - 12.12.21/17.12.1961/XNUMX , fødselsdato - XNUMX, etc. WorldState og det distribuerte registeret må være konsistente blant alle deltakere i en gitt kanal.
Siden Hyperledger Fabric er et nettverk der alle deltakerne er kjent og autentisert, bruker det en dedikert sertifiseringsinstans – CA (Certification Authority). CA opererer basert på X.509-standarden og offentlig nøkkelinfrastruktur - PKI.
Medlemstjeneste er en tjeneste der medlemmer bekrefter at et objekt tilhører en bestemt organisasjon eller kanal.
En transaksjon – i de fleste tilfeller er å skrive nye data til et distribuert register.
Det er også transaksjoner for opprettelse av kanaler eller smarte kontrakter. Transaksjonen initieres av brukerapplikasjonen og avsluttes med en post i den distribuerte reskontroen.
En kanal er et lukket undernettverk som består av to eller flere blokkjedenettverksdeltakere, designet for å utføre konfidensielle transaksjoner innenfor en begrenset, men kjent krets av deltakere. Kanalen bestemmes av deltakerne, dets distribuerte register, smarte kontrakter, bestillingstjeneste, WorldState. Hver kanaldeltaker må være autorisert til å få tilgang til kanalen og ha rett til å utføre ulike typer transaksjoner. Autorisasjon utføres ved hjelp av Medlemstjenesten.
Typisk transaksjonsutførelsesscenario
Deretter vil jeg snakke om et typisk transaksjonsutførelsesscenario ved å bruke prosjektet vårt som eksempel.
Som en del av vårt interne prosjekt opprettet vi Hyperledger Fabric-nettverket, som er designet for å registrere og gjøre rede for studenter som kommer inn på universiteter. Vårt nettverk består av to organisasjoner som tilhører Universitet A og Universitet B. Hver organisasjon inneholder en klientapplikasjon, samt sin egen Committing and Endorsing Peer. Vi bruker også fellestjenestene Bestillingstjeneste, Medlemsservice og Sertifiseringsinstans.
1) Igangsetting av transaksjon
En brukerapplikasjon, som bruker Hyperledger Fabric SDK, starter en transaksjonsforespørsel og sender forespørselen til noder med smarte kontrakter. Forespørselen kan være å endre eller lese fra et distribuert register (Ledger). Hvis vi vurderer et eksempel på vår testsystemkonfigurasjon for regnskap for universitetsstudenter, sender klientapplikasjonen en transaksjonsforespørsel til nodene til universitetene A og B, som er inkludert i godkjenningspolicyen til den kalte smarte kontrakten. Node A er en node som er plassert ved universitetet som registrerer den innkommende studenten, og node B er en node som ligger ved et annet universitet. For at en transaksjon skal lagres i et distribuert register, er det nødvendig at alle noder som i henhold til forretningslogikk skal godkjenne transaksjonen, gjennomfører smarte kontrakter med samme resultat. Noden En brukerapplikasjon, som bruker Hyperledger Fabric SDK-verktøyene, henter godkjenningspolicyen og lærer hvilke noder en transaksjonsforespørsel skal sendes til. Dette er en forespørsel om å påkalle en spesifikk smart kontrakt (kjedekodefunksjon) for å lese eller skrive visse data til et distribuert register. Teknisk sett bruker klient-SDK-en den tilsvarende funksjonen, hvis API overføres til et bestemt objekt med transaksjonsparametere, og legger også til en klientsignatur og sender disse dataene via protokollbuffer over gRPC til de aktuelle nodene (godkjenner peers).
Bilde 2. Starte en transaksjon
2) Gjennomføring av smart kontrakt
Noder (Endorsing Peers), etter å ha mottatt en forespørsel om å utføre en transaksjon, sjekke klientsignaturen og hvis alt er i orden, tar de et objekt med forespørselsdataene og kjører en simulering av utførelsen av en smart kontrakt (kjedekodefunksjon) med disse dataene. En smart kontrakt er forretningslogikken til en transaksjon, et visst sett med betingelser og instruksjoner (i vårt tilfelle er dette verifisering av en student, er dette en ny student, eller er han allerede registrert, aldersbekreftelse, etc.). For å utføre den smarte kontrakten trenger du også data fra WorldState. Som et resultat av simulering av en smart kontrakt på godkjennende peer, oppnås to sett med data – Read Set og Write Set. Lesesett og skrivesett er de originale og nye WorldState-verdiene. (ny – i betydningen oppnådd under simulering av en smart kontrakt).
Bilde 3. Gjennomføring av en smart kontrakt
3) Returnere data til klientapplikasjonen
Etter å ha gjennomført en simulering av den smarte kontrakten, returnerer Endorsing Peers de originale dataene og resultatet av simuleringen, samt RW-settet, signert av deres sertifikat, til klientapplikasjonen. På dette stadiet skjer det ingen endringer i det distribuerte registret. Klientapplikasjonen sjekker Endorsing Peer-signaturen, og sammenligner også de opprinnelige transaksjonsdataene som ble sendt og dataene som ble returnert (det vil si at den sjekker om de originale dataene som transaksjonen ble simulert på har blitt forvrengt). Hvis transaksjonen kun var for å lese data fra registeret, mottar klientapplikasjonen følgelig det nødvendige lesesettet, og dette fullfører vanligvis transaksjonen uten å endre det distribuerte registeret. Ved en transaksjon som må endre data i registeret, kontrollerer klientapplikasjonen i tillegg implementeringen av godkjenningspolicyen. Det er mulig at en klientapplikasjon ikke sjekker resultatet av å utføre godkjenningspolicyen, men Hyperledger Fabric-plattformen sørger i dette tilfellet for å sjekke policyer på noder (Committing Peers) på stadiet for å legge til en transaksjon i registeret.
Bilde 4. Returnerer data til klientapplikasjonen
4) Sende RW-sett til bestillingsfeller
Klientapplikasjonen sender transaksjonen sammen med tilhørende data til bestillingstjenesten. Dette inkluderer RW-settet, godkjennende peers-signaturer og kanal-ID.
Bestillingstjeneste – basert på navnet er hovedfunksjonen til denne tjenesten å ordne innkommende transaksjoner i riktig rekkefølge. Samt dannelsen av en ny blokk av det distribuerte registret og garantert levering av nye genererte blokker til alle Commiting-noder, og dermed sikre datakonsistens på alle noder som inneholder det distribuerte registret (Committing peers). Samtidig endrer ikke selve Bestillingstjenesten registeret på noen måte. Bestillingstjeneste er en viktig komponent i systemet, så det er en klynge av flere noder. Bestillingstjenesten kontrollerer ikke transaksjonen for gyldighet, den aksepterer bare en transaksjon med en bestemt kanalidentifikator, arrangerer innkommende transaksjoner i en bestemt rekkefølge og danner nye blokker av det distribuerte registeret fra dem. Én bestillingstjeneste kan betjene flere kanaler samtidig. Bestillingstjenesten inkluderer en Kafka-klynge, som opprettholder den korrekte (uforanderlige) transaksjonskøen (se punkt 7).
Bilde 5. Sender RW-sett til bestilling av peers
5) Sende genererte blokker til Committing Peer
Blokker generert i bestillingstjenesten overføres (kringkastes) til alle nettverksnoder. Hver node, etter å ha mottatt en ny blokk, sjekker den for samsvar med godkjenningspolicyen, sjekker at alle godkjenningskolleger mottok det samme resultatet (skrivesett) som et resultat av smartkontraktsimuleringen, og sjekker også om de opprinnelige verdiene har endret (det vil si Read Set - data lest av smartkontrakten fra WorldState) fra det øyeblikket transaksjonen ble igangsatt. Hvis alle betingelser er oppfylt, merkes transaksjonen som gyldig, ellers får transaksjonen statusen ugyldig.
Bilde 6. Sender genererte blokker til Committing Peer
6) Legge til en blokk i registeret
Hver node legger til en transaksjon til sin lokale kopi av det distribuerte registeret, og hvis transaksjonen er gyldig, blir skrivesettet brukt på WorldState (nåværende tilstand), og følgelig nye verdier for objektene som ble påvirket av transaksjonen er skrevet. Hvis en transaksjon mottok et token som ikke er gyldig (for eksempel to transaksjoner skjedde med de samme objektene innenfor samme blokk, vil en av transaksjonene vise seg å være ugyldig, siden de opprinnelige verdiene allerede er endret av en annen transaksjon). Denne transaksjonen legges også til den distribuerte hovedboken med et ugyldig token, men skrivesettet til denne transaksjonen brukes ikke på gjeldende verdensstat og endrer følgelig ikke objektene som deltar i transaksjonen. Etter dette sendes en melding til brukerapplikasjonen om at transaksjonen er permanent lagt til det distribuerte registeret, samt status for transaksjonen, det vil si om den er gyldig eller ikke...
Bilde 7. Legge til en blokk i registret
BESTILLINGSSERVICE
Bestillingstjenesten består av en Kafka-klynge med tilsvarende ZooKeeper-noder og bestillingstjenestenoder (OSN), som står mellom bestillingstjenestekundene og Kafka-klyngen. Kafka-klyngen er en distribuert, feiltolerant flyt (meldings) administrasjonsplattform. Hver kanal (emne) i Kafka er en uforanderlig sekvens av poster som bare støtter å legge til en ny post (slette en eksisterende er ikke mulig). En illustrasjon av emnestrukturen er vist nedenfor. Det er denne egenskapen til Kafka som brukes til å bygge en blokkjedeplattform.
hentet fra kafka.apache.org
- Bilde 8. Emnestruktur for bestillingstjeneste*
Nyttige lenker
Anerkjennelser
Jeg vil gjerne uttrykke min dype takknemlighet til mine kolleger for deres hjelp med å utarbeide denne artikkelen:
Nikolay Marin
Igor Khapov
Dmitrij Gorbatsjov
Alexander Zemtsov
Ekaterina Guseva
Kilde: www.habr.com