En Blockchain-plattform för företaget
God eftermiddag, kära läsare, jag heter Nikolai Nefedov, jag är en teknisk specialist från IBM, i den här artikeln skulle jag vilja presentera dig för blockchain-plattformen - Hyperledger Fabric. Plattformen är avsedd för att bygga affärsapplikationer på företagsnivå (Enterprise class). Nivån på artikeln är för oförberedda läsare med grundläggande kunskaper om IT-teknik.
Hyperledger Fabric är ett öppen källkodsprojekt, en av grenarna till Hyperledger open source-projektet, ett konsortium av Linux Foundation. Hyperledger Fabric lanserades ursprungligen av Digital Assets och IBM. Huvudfunktionen hos Hyperledger Fabric-plattformen är dess fokus på företagsapplikationer. Därför utvecklades plattformen med hänsyn till den höga hastigheten på transaktioner och deras låga kostnad, samt identifieringen av alla deltagare. Dessa fördelar uppnås genom att separera transaktionsverifieringstjänsten och bilda nya block av det distribuerade registret, samt använda en certifikatutfärdare och auktorisera deltagare.
Min artikel är en del av en serie artiklar om Hyperledger Fabric där vi beskriver projektet med ett system för att registrera studenter som kommer in på ett universitet.
Allmän arkitektur för Hyperledger Fabric
Hyperledger Fabric är ett distribuerat blockchain-nätverk som består av olika funktionella komponenter som är installerade på nätverksnoder. Hyperledger Fabric-komponenter är Docker-behållare som kan laddas ner fritt från DockerHub. Hyperledger Fabric kan också köras i en Kubernetes-miljö.
För att skriva smarta kontrakt (kedjekod i sammanhanget Hyperledger Fabric) använde vi Golang (även om Hyperledger Fabric låter dig använda andra språk). För att utveckla en anpassad applikation användes i vårt fall Node.js med motsvarande Hyperledger Fabric SDK.
Noderna kör affärslogik (smart kontrakt) – kedjekod, lagrar tillståndet för det distribuerade registret (reskontradata) och utför andra plattformssystemtjänster. En nod är bara en logisk enhet, olika noder kan finnas på samma fysiska server. Mycket viktigare är hur noderna är grupperade (Trusted domain) och vilka funktioner i blockkedjenätverket de är associerade med.
Den allmänna arkitekturen ser ut så här:
Bild 1. Allmän arkitektur för Hyperledger-tyg
Användarapplikation (Submitting Client) är en applikation med vilken användare arbetar med blockchain-nätverket. För att arbeta måste du gå igenom auktorisation och ha lämpliga rättigheter för olika typer av åtgärder på nätverket.
Peers (noder) kommer i flera roller:
- Endossing Peer är en nod som simulerar exekveringen av en transaktion (exekverar den smarta kontraktskoden). Efter validering och exekvering av det smarta kontraktet returnerar noden exekveringsresultaten till klientapplikationen tillsammans med sin signatur.
- Ordering Service är en distribuerad tjänst på flera noder, den används för att bilda nya block av den distribuerade reskontran och skapa en sekvens för att utföra transaktioner. Ordering Service lägger inte till nya block till registret (Flyttat till Committing Peers för bättre prestanda).
- Committing Peer - en nod som innehåller ett distribuerat register och lägger till nya block till registret (som bildades av beställningstjänsten). Alla Committing Peers innehåller en lokal kopia av den distribuerade reskontran. Innan ett nytt block läggs till lokalt kontrollerar den förpliktande peeren alla transaktioner inom blocket för giltighet.
Endossement Policy är en policy för att kontrollera en transaktions giltighet. Dessa policyer definierar den nödvändiga uppsättningen noder på vilka det smarta kontraktet måste utföras för att transaktionen ska erkännas som giltig.
Det distribuerade registret - Lerger - består av två delar: WolrldState (även kallad State DataBase) och BlockChain.
BlockChain är en kedja av block som lagrar register över alla ändringar som har inträffat i distribuerade reskontraobjekt.
WolrldState är en distribuerad registerkomponent som lagrar de aktuella (extrema) värdena för alla distribuerade registerobjekt.
WorldState är en databas, i grundversionen - LevelDB eller mer komplex - CouchDB, som innehåller nyckel-värdepar, till exempel: Förnamn - Ivan, Efternamn - Ivanov, registreringsdatum i systemet - 12.12.21/17.12.1961/XNUMX, datum för födelse - XNUMX-XNUMX-XNUMX, etc. WorldState och den distribuerade huvudboken måste vara konsekventa för alla medlemmar i en given kanal.
Eftersom Hyperledger Fabric är ett nätverk där alla deltagare är kända och autentiserade, används här en dedikerad certifieringsmyndighet - CA (Certification Authority). CA arbetar på grundval av X.509-standarden och infrastruktur för publik nyckel - PKI.
Medlemstjänst är en tjänst genom vilken medlemmar verifierar att ett objekt tillhör en viss organisation eller kanal.
En transaktion är i de flesta fall en registrering av ny data i en distribuerad reskontra.
Det finns också transaktioner för att skapa kanaler eller smarta kontrakt. Transaktionen initieras av användarapplikationen och avslutas med en skrivning till den distribuerade reskontran.
Channel (Channel) är ett slutet subnät bestående av två eller flera deltagare i blockchain-nätverket, utformat för att genomföra konfidentiella transaktioner inom en begränsad, men känd, krets av deltagare. Kanalen bestäms av deltagarna, dess distribuerade reskontra, smarta kontrakt, beställningstjänst, WorldState. Varje kanalmedlem måste ha behörighet att komma åt kanalen och ha rätt att utföra olika typer av transaktioner. Auktorisering utförs med hjälp av Medlemstjänsten.
Typiskt scenario för genomförande av transaktioner
Därefter skulle jag vilja prata om ett typiskt scenario för att utföra en transaktion med exemplet från vårt projekt.
Som en del av vårt interna projekt har vi skapat ett Hyperledger Fabric-nätverk, som är utformat för att registrera och registrera studenter som kommer in på universitet. Vårt nätverk består av två organisationer, ägda av universitet A och universitet B. Varje organisation innehåller en kundansökan, samt en egen Committing and Endorsing Peer. Vi använder också de vanliga tjänsterna för beställningstjänst, medlemstjänst och certifikatutfärdare.
1) Transaktionsinitiering
Användarapplikationen, med hjälp av Hyperledger Fabric SDK, initierar en transaktionsbegäran och skickar begäran till noder med smarta kontrakt. Begäran kan vara att ändra eller läsa från en distribuerad reskontra (Ledger). Om vi överväger ett exempel på vår testkonfiguration av systemet för redovisning av universitetsstudenter, skickar klientapplikationen en transaktionsbegäran till noderna på universitet A och B, som ingår i godkännandepolicyn för det kallade smarta kontraktet. Nod A är en nod som är belägen på universitetet som registrerar en inkommande student, och nod B är en nod som ligger på ett annat universitet. För att en transaktion ska sparas i en distribuerad reskontra krävs att alla noder som enligt affärslogiken ska godkänna transaktionen framgångsrikt utför smarta kontrakt med samma resultat. Användarapplikationen av nod A, med hjälp av Hyperledger Fabric SDK-verktygen, tar emot endossementpolicyn (godkännandepolicy) och tar reda på vilka noder som ska skickas en transaktionsbegäran till. Detta är en begäran om att anropa (anropa) ett visst smart kontrakt (kedjekodsfunktion) för att läsa eller skriva viss data till den distribuerade huvudboken. Tekniskt sett använder klient-SDK:n motsvarande funktion, vars API skickas ett objekt med transaktionsparametrar, och lägger även till en klientsignatur och skickar dessa data via protokollbuffert över gRPC till lämpliga noder (endosserande peers).
Bild 2. Transaktionsinitiering
2) Smart kontraktsutförande
Noder (Endorsing Peers), efter att ha fått en förfrågan om att genomföra en transaktion, kontrollera klientsignaturen och om allt är i sin ordning, tar de ett objekt med förfrågningsdata och kör en simulering av exekveringen av ett smart kontrakt (chaincode-funktion) med dessa uppgifter. Ett smart kontrakt är affärslogiken för en transaktion, en viss uppsättning villkor och instruktioner (i vårt fall är detta en studentcheck, är det en ny student, eller är han redan registrerad, ålderskontroll, etc.). För att utföra ett smart kontrakt behöver du även data från WorldState. Som ett resultat av den smarta kontraktssimuleringen på Endorsing-peeren erhålls två datamängder - Read Set och Write Set. Read Set och Write Set är de ursprungliga och nya WorldState-värdena. (ny - i den mening som erhålls genom att simulera ett smart kontrakt).
Bild 3. Smart kontraktsutförande
3) Returnera data till klientapplikationen
Efter simuleringen av det smarta kontraktet returnerar Endorsing Peers till klientapplikationen de initiala data och resultatet av simuleringen, såväl som RW-setet signerat av deras certifikat. I detta skede finns inga ändringar i den distribuerade reskontran. Klientapplikationen verifierar signaturen för den godkända peeren och jämför även den ursprungliga transaktionsdata som skickades och den data som returnerades (det vill säga den kontrollerar om den ursprungliga data som transaktionen simulerades har blivit korrupt). Om transaktionen endast var för att läsa data från registret, får klientapplikationen följaktligen den nödvändiga läsuppsättningen, och på detta slutförs transaktionen vanligtvis framgångsrikt utan att ändra det distribuerade registret. Vid en transaktion som skulle ändra data i registret kontrollerar klientapplikationen dessutom om Endorsing-policyn har implementerats. Det är möjligt att klientapplikationen inte kontrollerar resultatet av exekveringen av endossementpolicyn, men Hyperledger Fabric-plattformen ger i det här fallet möjlighet att kontrollera policyerna på noderna (Committing Peers) i det skede då en transaktion läggs till i registret.
Bild 4. Returnera data till klientapplikationen
4) Skicka RW-uppsättningar till beställande peers
Klientapplikationen skickar transaktionen tillsammans med relaterade data till beställningstjänsten. Detta inkluderar RW-uppsättningen, signaturer från stödjande kamrater och kanal-ID.
Beställningstjänst - Baserat på namnet är denna tjänsts huvudsakliga funktion att bygga in inkommande transaktioner i rätt ordning. Samt bildandet av ett nytt block av det distribuerade registret och den garanterade leveransen av nya genererade block till alla Commiting-noder, vilket säkerställer datakonsistens på alla noder som innehåller det distribuerade registret (Committing peers). Samtidigt ändrar inte själva beställningstjänsten registret på något sätt. Beställningstjänst är en viktig komponent i systemet, så det är ett kluster av flera noder. Beställningstjänsten kontrollerar inte transaktionens giltighet, den accepterar helt enkelt en transaktion med ett specifikt kanal-ID, ordnar inkommande transaktioner i en specifik order och bildar nya block av den distribuerade reskontran från dem. En beställningstjänst kan betjäna flera kanaler samtidigt. Beställningstjänsten inkluderar ett Kafka-kluster, som upprätthåller korrekt (oförändrad) transaktionskö (se punkt 7).
Bild 5. Skickar RW-uppsättningar till Ordering Peers
5) Skicka de genererade blocken till Committing Peer
Blocken som bildas i beställningstjänsten sänds till alla nätverksnoder. Varje nod, efter att ha fått ett nytt block, kontrollerar att det överensstämmer med Endorsing Policy, kontrollerar att alla Endorsing Peers fick samma resultat (Write Set) som ett resultat av den smarta kontraktssimuleringen, och kontrollerar även om de ursprungliga värdena har ändrats (det vill säga - Read Set - data som läses av det smarta kontraktet från WorldState) sedan initieringen av transaktionen. Om alla villkor är uppfyllda markeras transaktionen som giltig, annars får transaktionen statusen ogiltig.
Bild 6. Skicka genererade block till Committing Peer
6) Lägga till ett block i registret
Varje nod lägger till en transaktion till sin lokala kopia av den distribuerade huvudboken, och om transaktionen är giltig appliceras Write Set på WorldState (nuvarande tillstånd), respektive nya värden för objekt som påverkades av transaktionen skrivs . Om en transaktion fick en token som inte är giltig (till exempel, det fanns två transaktioner med samma objekt inom samma block, kommer en av transaktionerna inte att vara giltig, eftersom de ursprungliga värdena redan har ändrats av en annan transaktion ). Denna transaktion läggs också till i den distribuerade huvudboken med en ogiltig markör, men skrivuppsättningen för denna transaktion gäller inte det aktuella tillståndet i WorldState och ändrar följaktligen inte objekten som deltar i transaktionen. Därefter skickas ett meddelande till användarapplikationen att transaktionen har lagts till i den distribuerade reskontran för alltid, liksom transaktionens status, det vill säga om den är giltig eller inte ...
Bild 7. Lägga till ett block i registret
BESTÄLLNINGSTJÄNST
Beställningstjänsten består av ett Kafka-kluster med motsvarande ZooKeeper-noder och en Beställningstjänstnoder (OSN) som sitter mellan Beställningstjänstkunderna och Kafka-klustret. Kafka-kluster är en distribuerad, feltolerant flödes (meddelande) hanteringsplattform. Varje kanal (ämne) i Kafka är en oföränderlig sekvens av poster som bara stöder att lägga till en ny post (det är inte möjligt att ta bort en befintlig). En illustration av ämnesstrukturen ges nedan. Det är denna egenskap hos Kafka som används för att bygga blockchain-plattformen.
hämtad från kafka.apache.org
- Bild 8. Ämnesstruktur för beställningstjänst*
Användbara länkar
Kvitteringar
Jag uttrycker min djupa tacksamhet till mina kollegor för deras hjälp med att förbereda artikeln:
Nikolai Marina
Igor Khapov
Dmitrij Gorbatjov
Alexander Zemtsov
Ekaterina Guseva
Källa: will.com