Eine Blockchain-Plattform für das Unternehmen
Guten Tag, liebe Leser, mein Name ist Nikolay Nefedov, ich bin technischer Spezialist bei IBM, in diesem Artikel möchte ich Ihnen die Blockchain-Plattform Hyperledger Fabric vorstellen. Die Plattform ist für die Erstellung von Geschäftsanwendungen der Enterprise-Klasse konzipiert. Das Niveau des Artikels richtet sich an unvorbereitete Leser mit Grundkenntnissen in IT-Technologien.
Hyperledger Fabric ist ein Open-Source-Projekt, einer der Zweige des Open-Source-Hyperledger-Projekts, einem Konsortium der Linux Foundation. Hyperledger Fabric wurde ursprünglich von Digital Assets und IBM gestartet. Das Hauptmerkmal der Hyperledger Fabric-Plattform ist ihr Fokus auf den Einsatz in Unternehmen. Daher wurde die Plattform unter Berücksichtigung der hohen Geschwindigkeit der Transaktionen und ihrer geringen Kosten sowie der Identifizierung aller Teilnehmer entwickelt. Diese Vorteile werden durch die Trennung des Transaktionsverifizierungsdienstes und die Bildung neuer Blöcke des verteilten Registers sowie die Nutzung einer Zertifizierungsstelle und Autorisierung der Teilnehmer erreicht.
Mein Artikel ist Teil einer Artikelserie über Hyperledger Fabric, in der wir ein Systemprojekt zur Erfassung von Studierenden an einer Universität beschreiben.
Allgemeine Architektur von Hyperledger Fabric
Hyperledger Fabric ist ein verteiltes Blockchain-Netzwerk, das aus verschiedenen Funktionskomponenten besteht, die auf Netzwerkknoten installiert sind. Hyperledger Fabric-Komponenten sind Docker-Container, die kostenlos von DockerHub heruntergeladen werden können. Hyperledger Fabric kann auch in einer Kubernetes-Umgebung ausgeführt werden.
Um Smart Contracts (Chaincode im Kontext von Hyperledger Fabric) zu schreiben, haben wir Golang verwendet (obwohl Hyperledger Fabric die Verwendung anderer Sprachen ermöglicht). Um eine benutzerdefinierte Anwendung zu entwickeln, haben wir in unserem Fall Node.js mit dem entsprechenden Hyperledger Fabric SDK verwendet.
Die Knoten führen Geschäftslogik (Smart Contract) – Chaincode – aus, speichern den Status der verteilten Registrierung (Ledger-Daten) und führen andere Systemdienste der Plattform aus. Ein Knoten ist lediglich eine logische Einheit; auf demselben physischen Server können verschiedene Knoten vorhanden sein. Viel wichtiger ist, wie die Knoten gruppiert sind (vertrauenswürdige Domäne) und mit welchen Funktionen des Blockchain-Netzwerks sie verbunden sind.
Die allgemeine Architektur sieht folgendermaßen aus:
Bild 1. Allgemeine Architektur von Hyperledger Fabric
Eine Benutzeranwendung (Submitting Client) ist eine Anwendung, mit der Benutzer mit dem Blockchain-Netzwerk arbeiten. Um arbeiten zu können, müssen Sie autorisiert sein und über die entsprechenden Rechte für verschiedene Arten von Aktionen im Netzwerk verfügen.
Peers haben verschiedene Rollen:
- Endorsing Peer ist ein Knoten, der die Ausführung einer Transaktion simuliert (den Smart-Contract-Code ausführt). Nach der Überprüfung und Ausführung des Smart Contracts sendet der Knoten die Ausführungsergebnisse zusammen mit seiner Signatur an die Clientanwendung zurück.
- Der Bestelldienst ist ein verteilter Dienst auf mehreren Knoten, der zum Generieren neuer Blöcke der verteilten Registrierung und zum Erstellen einer Warteschlange für die Ausführung von Transaktionen verwendet wird. Der Bestelldienst fügt der Registrierung keine neuen Blöcke hinzu (diese Funktion wurde zur Verbesserung der Leistung in „Committing Peers“ verschoben).
- Committing Peer ist ein Knoten, der eine verteilte Registrierung enthält und der Registrierung neue Blöcke hinzufügt (die vom Bestelldienst generiert wurden). Alle Commiting Peers enthalten eine lokale Kopie des Distributed Ledgers. Commiting Peer prüft alle Transaktionen innerhalb des Blocks auf Gültigkeit, bevor lokal ein neuer Block hinzugefügt wird.
Die Endorsement-Richtlinie ist die Richtlinie zur Überprüfung der Gültigkeit einer Transaktion. Diese Richtlinien definieren den erforderlichen Satz von Knoten, auf denen der Smart Contract ausgeführt werden muss, damit die Transaktion als gültig anerkannt wird.
Das verteilte Register – Lerger – besteht aus zwei Teilen: WolrldState (auch State DataBase genannt) und BlockChain.
BlockChain ist eine Kette von Blöcken, die Aufzeichnungen aller Änderungen speichert, die an verteilten Registrierungsobjekten vorgenommen wurden.
WolrldState ist eine Distributed-Ledger-Komponente, die die aktuellen (aktuellen) Werte aller Distributed-Ledger-Objekte speichert.
WorldState представляет собой базу данных, в базовом варианте — LevelDB или более сложная – CouchDB, которая содержит пары ключ — значение, например: Имя – Иван, Фамилия — Иванов, дата регистрации в системе – 12.12.21, дата рождения — 17.12.1961, usw. WorldState und die verteilte Registrierung müssen für alle Teilnehmer eines bestimmten Kanals konsistent sein.
Da es sich bei Hyperledger Fabric um ein Netzwerk handelt, in dem alle Teilnehmer bekannt und authentifiziert sind, nutzt es eine dedizierte Zertifizierungsstelle – CA (Certification Authority). CA arbeitet auf Basis des X.509-Standards und der Public-Key-Infrastruktur – PKI.
Der Mitgliedschaftsdienst ist ein Dienst, mit dem Mitglieder überprüfen, ob ein Objekt zu einer bestimmten Organisation oder einem bestimmten Kanal gehört.
Bei einer Transaktion handelt es sich in den meisten Fällen um das Schreiben neuer Daten in eine verteilte Registrierung.
Es gibt auch Transaktionen zur Erstellung von Kanälen oder Smart Contracts. Die Transaktion wird von der Benutzeranwendung initiiert und endet mit einem Eintrag im Distributed Ledger.
Ein Channel ist ein geschlossenes Subnetzwerk bestehend aus zwei oder mehr Blockchain-Netzwerkteilnehmern, das dazu dient, vertrauliche Transaktionen innerhalb eines begrenzten, aber bekannten Teilnehmerkreises durchzuführen. Der Kanal wird durch die Teilnehmer, sein verteiltes Register, intelligente Verträge, Bestellservice und WorldState bestimmt. Jeder Kanalteilnehmer muss zum Zugriff auf den Kanal berechtigt sein und das Recht haben, verschiedene Arten von Transaktionen durchzuführen. Die Autorisierung erfolgt über den Membership Service.
Typisches Transaktionsausführungsszenario
Als nächstes möchte ich am Beispiel unseres Projekts über ein typisches Transaktionsausführungsszenario sprechen.
Im Rahmen unseres internen Projekts haben wir das Hyperledger Fabric-Netzwerk erstellt, das für die Registrierung und Abrechnung von Studierenden an Universitäten konzipiert ist. Unser Netzwerk besteht aus zwei Organisationen, die zu Universität A und Universität B gehören. Jede Organisation enthält eine Kundenanwendung sowie einen eigenen Committing- und Endorsing-Peer. Darüber hinaus nutzen wir die gemeinsamen Dienste Bestellservice, Mitgliedschaftsservice und Zertifizierungsstelle.
1) Einleitung der Transaktion
Eine Benutzeranwendung initiiert mithilfe des Hyperledger Fabric SDK eine Transaktionsanforderung und sendet die Anforderung an Knoten mit Smart Contracts. Die Anforderung kann darin bestehen, eine verteilte Registrierung (Ledger) zu ändern oder daraus zu lesen. Wenn wir ein Beispiel unserer Testsystemkonfiguration für die Abrechnung von Universitätsstudenten betrachten, sendet die Client-Anwendung eine Transaktionsanforderung an die Knoten der Universitäten A und B, die in der Endorsement-Richtlinie des aufgerufenen Smart Contracts enthalten sind. Knoten A ist ein Knoten, der sich an der Universität befindet, die den ankommenden Studenten registriert, und Knoten B ist ein Knoten, der sich an einer anderen Universität befindet. Damit eine Transaktion in einer verteilten Registrierung gespeichert werden kann, ist es notwendig, dass alle Knoten, die gemäß der Geschäftslogik die Transaktion genehmigen müssen, Smart Contracts erfolgreich mit demselben Ergebnis ausführen. Die Knoten-A-Benutzeranwendung ruft mithilfe der Hyperledger Fabric SDK-Tools die Endorsement-Richtlinie ab und erfährt, an welche Knoten eine Transaktionsanforderung gesendet werden soll. Hierbei handelt es sich um eine Anfrage zum Aufrufen eines bestimmten Smart-Vertrags (Chaincode-Funktion), um bestimmte Daten in einer verteilten Registrierung zu lesen oder in sie zu schreiben. Technisch gesehen verwendet das Client-SDK die entsprechende Funktion, deren API ein bestimmtes Objekt mit Transaktionsparametern übergibt, außerdem eine Client-Signatur hinzufügt und diese Daten per Protokollpuffer über gRPC an die entsprechenden Knoten (Endorsing-Peers) sendet.
Bild 2. Initiierung einer Transaktion
2) Ausführung eines Smart Contracts
Knoten (Endorsing Peers), die eine Anfrage zur Durchführung einer Transaktion erhalten haben, prüfen die Client-Signatur und wenn alles in Ordnung ist, nehmen sie ein Objekt mit den Anfragedaten und führen eine Simulation der Ausführung eines Smart Contracts (Chaincode-Funktion) durch diese Daten. Ein Smart Contract ist die Geschäftslogik einer Transaktion, ein bestimmter Satz von Bedingungen und Anweisungen (in unserem Fall ist dies die Überprüfung eines Studenten, ob es sich um einen neuen Studenten handelt oder ob er bereits registriert ist, eine Altersüberprüfung usw.). Um den Smart Contract auszuführen, benötigen Sie außerdem Daten von WorldState. Als Ergebnis der Simulation eines Smart Contracts auf dem Endorsing-Peer werden zwei Datensätze erhalten – Read Set und Write Set. Read Set und Write Set sind die ursprünglichen und neuen WorldState-Werte. (neu – im Sinne der Simulation eines Smart Contracts).
Bild 3. Ausführung eines Smart Contracts
3) Zurückgeben von Daten an die Clientanwendung
Nach der Durchführung einer Simulation des Smart Contracts geben Endorsing Peers die Originaldaten und das Ergebnis der Simulation sowie das von ihrem Zertifikat signierte RW-Set an die Client-Anwendung zurück. Zu diesem Zeitpunkt treten keine Änderungen in der verteilten Registrierung auf. Die Clientanwendung prüft die Endorsing-Peer-Signatur und vergleicht außerdem die ursprünglich gesendeten und die zurückgegebenen Transaktionsdaten (d. h. sie prüft, ob die Originaldaten, auf denen die Transaktion simuliert wurde, verfälscht wurden). Wenn es sich bei der Transaktion nur um das Lesen von Daten aus der Registry handelte, erhält die Client-Anwendung entsprechend den erforderlichen Read Set und schließt die Transaktion in der Regel erfolgreich ab, ohne die verteilte Registry zu ändern. Im Falle einer Transaktion, die Daten in der Registry ändern muss, prüft die Client-Anwendung zusätzlich die Umsetzung der Endorsing-Richtlinie. Es ist möglich, dass eine Clientanwendung das Ergebnis der Ausführung der Endorsement Policy nicht überprüft, aber die Hyperledger Fabric-Plattform sieht in diesem Fall die Überprüfung von Richtlinien auf Knoten (Committing Peers) in der Phase des Hinzufügens einer Transaktion zur Registrierung vor.
Bild 4. Daten an die Client-Anwendung zurückgeben
4) Senden von RW-Sets an bestellende Peers
Die Clientanwendung sendet die Transaktion zusammen mit den zugehörigen Daten an den Bestelldienst. Dazu gehören das RW-Set, die Signaturen der Endorsing-Peers und die Kanal-ID.
Bestellservice – dem Namen nach besteht die Hauptfunktion dieses Dienstes darin, eingehende Transaktionen in die richtige Reihenfolge zu bringen. Sowie die Bildung eines neuen Blocks der verteilten Registrierung und die garantierte Lieferung neu generierter Blöcke an alle Commiting-Knoten, wodurch die Konsistenz der Daten auf allen Knoten sichergestellt wird, die die verteilte Registrierung enthalten (Committing-Peers). Gleichzeitig verändert der Bestelldienst selbst die Registrierung in keiner Weise. Der Bestelldienst ist eine wichtige Komponente des Systems und daher ein Cluster aus mehreren Knoten. Der Bestelldienst prüft die Transaktion nicht auf Gültigkeit, sondern akzeptiert lediglich eine Transaktion mit einer bestimmten Kanalkennung, ordnet eingehende Transaktionen in einer bestimmten Reihenfolge und bildet daraus neue Blöcke der verteilten Registrierung. Ein Bestellservice kann mehrere Kanäle gleichzeitig bedienen. Der Bestelldienst umfasst einen Kafka-Cluster, der die korrekte (unveränderliche) Transaktionswarteschlange verwaltet (siehe Punkt 7).
Bild 5. Senden von RW-Sets an bestellende Peers
5) Senden der generierten Blöcke an den Commit-Peer
Im Ordering Service generierte Blöcke werden an alle Netzwerkknoten übertragen (Broadcast). Nachdem jeder Knoten einen neuen Block erhalten hat, prüft er, ob er der Endorsing Policy entspricht, prüft, ob alle Endorsing Peers das gleiche Ergebnis (Write Set) als Ergebnis der Smart-Contract-Simulation erhalten haben, und prüft auch, ob die ursprünglichen Werte vorhanden sind geändert (d. h. Lesesatz – vom Smart-Vertrag von WorldState gelesene Daten) ab dem Moment, in dem die Transaktion initiiert wurde. Wenn alle Bedingungen erfüllt sind, wird die Transaktion als gültig markiert, andernfalls erhält die Transaktion den Status ungültig.
Bild 6. Generierte Blöcke an Commit-Peer senden
6) Hinzufügen eines Blocks zur Registrierung
Jeder Knoten fügt seiner lokalen Kopie der verteilten Registrierung eine Transaktion hinzu. Wenn die Transaktion gültig ist, wird der Schreibsatz auf den WorldState (aktueller Status) und dementsprechend auf neue Werte der Objekte angewendet, die davon betroffen waren Transaktion geschrieben werden. Wenn eine Transaktion ein ungültiges Token erhalten hat (z. B. zwei Transaktionen mit denselben Objekten innerhalb desselben Blocks), wird sich eine der Transaktionen als ungültig erweisen, da die ursprünglichen Werte bereits durch eine andere geändert wurden Transaktion). Diese Transaktion wird ebenfalls mit einem ungültigen Token zum Distributed Ledger hinzugefügt, der Write Set dieser Transaktion wird jedoch nicht auf den aktuellen WorldState angewendet und ändert dementsprechend nicht die an der Transaktion beteiligten Objekte. Danach wird eine Benachrichtigung an die Benutzeranwendung gesendet, dass die Transaktion dauerhaft zur verteilten Registrierung hinzugefügt wurde, sowie der Status der Transaktion, d. h. ob sie gültig ist oder nicht ...
Bild 7. Hinzufügen eines Blocks zur Registrierung
BESTELLSERVICE
Der Ordering Service besteht aus einem Kafka-Cluster mit entsprechenden ZooKeeper-Knoten und Ordering Service Nodes (OSN), die zwischen den Ordering Service-Clients und dem Kafka-Cluster stehen. Der Kafka-Cluster ist eine verteilte, fehlertolerante Fluss-(Nachrichten-)Verwaltungsplattform. Jeder Kanal (Thema) in Kafka ist eine unveränderliche Folge von Datensätzen, die nur das Hinzufügen eines neuen Datensatzes unterstützt (das Löschen eines vorhandenen Datensatzes ist nicht möglich). Nachfolgend finden Sie eine Darstellung der Themenstruktur. Es ist diese Eigenschaft von Kafka, die zum Aufbau einer Blockchain-Plattform genutzt wird.
entnommen aus kafka.apache.org
- Bild 8. Themenstruktur des Bestellservices*
Nützliche Links
Danksagung
Ich möchte meinen Kollegen meinen tiefen Dank für ihre Hilfe bei der Erstellung dieses Artikels aussprechen:
Nikolay Marin
Igor Khapov
Dmitri Gorbatschow
Alexander Zemtsov
Ekaterina Guseva
Source: habr.com