Guten Tag, liebe Leser, mein Name ist Nikolai Nefedov, ich bin technischer Berater bei IBM. In diesem Artikel möchte ich Ihnen die Blockchain-Plattform Hyperledger Fabric vorstellen. Die Plattform dient zum Erstellen von Geschäftsanwendungen auf Unternehmensebene (Enterprise-Klasse). Artikelebene - für ungeschulte Leser mit Grundkenntnissen in IT-Technologie.
Hyperledger Fabric ist ein Open-Source-Projekt, einer der Zweige des Open-Source-Projekts Hyperledger, einem Linux Foundation-Konsortium. Hyperledger Fabric wurde ursprünglich von Digital Assets und IBM gestartet. Das Hauptmerkmal der Hyperledger Fabric-Plattform ist der Fokus auf Unternehmensanwendungen. Daher wurde die Plattform unter Berücksichtigung der hohen Transaktionsgeschwindigkeit 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 durch die Verwendung einer Zertifizierungsstelle und die Autorisierung der Teilnehmer erreicht.
Mein Artikel ist Teil einer Reihe von Artikeln über Hyperledger Fabric, in deren Rahmen wir den Entwurf eines Systems zur Bilanzierung von Studenten beschreiben, die an einer Universität studieren.
Allgemeine Hyperledger-Fabric-Architektur
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 Kubernetes-Umgebungen ausgeführt werden.
Zum Schreiben intelligenter Verträge (Kettencode im Kontext von Hyperledger Fabric) haben wir Golang verwendet (obwohl Sie mit Hyperledger Fabric andere Sprachen verwenden können). In unserem Fall wurde Node.js mit dem entsprechenden Hyperledger Fabric SDK verwendet, um eine benutzerdefinierte Anwendung zu entwickeln.
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 nur 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 welchen Funktionen des Blockchain-Netzwerks sie zugeordnet sind.
Die allgemeine Architektur ist wie folgt:
Bild 1. Allgemeine Architektur des Hyperledger-Gewebes
Benutzeranwendung (Submission Client) - 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.
Gleichaltrige haben verschiedene Rollen:
- Endorsing Peer - Ein Knoten, der die Ausführung einer Transaktion simuliert (führt einen intelligenten Vertragscode aus). Nach dem Überprüfen und Ausführen des Smart-Vertrags gibt der Knoten die Ergebnisse der Client-Anwendung zusammen mit ihrer Signatur zurück.
- Bestelldienst - Ein verteilter Dienst auf mehreren Knoten, der dazu dient, neue Blöcke einer verteilten Registrierung zu bilden und eine Folge von Transaktionen zu erstellen. Der Bestellservice fügt der Registrierung keine neuen Blöcke hinzu (Um die Leistung zu verbessern, wurde diese Funktion an Committing Peers übertragen).
- Committing Peer - Ein Knoten, der eine verteilte Registrierung enthält und der Registrierung (die vom Bestelldienst gebildet wurde) neue Blöcke hinzufügt. Alle Committing Peers enthalten eine lokale Kopie der verteilten Registrierung. Der Committing Peer überprüft vor dem lokalen Hinzufügen eines neuen Blocks alle Transaktionen innerhalb des Blocks auf Gültigkeit.
Die Endorsement-Richtlinie ist eine Transaktionsvalidierungsrichtlinie. Diese Richtlinien bestimmen die erforderlichen Knoten, auf denen ein intelligenter Vertrag ausgeführt werden muss, damit die Transaktion als gültig erkannt wird.
Die verteilte Registrierung - Lerger - besteht aus zwei Teilen: WolrldState (auch als State DataBase bezeichnet) und BlockChain.
BlockChain ist eine Blockkette, in der Aufzeichnungen aller Änderungen gespeichert werden, die an verteilten Registrierungsobjekten vorgenommen wurden.
WolrldState ist eine Komponente einer verteilten Registrierung, die die aktuellen (Extrem-) Werte aller Objekte in einer verteilten Registrierung speichert.
WorldState ist eine Datenbank in der Basisversion - LevelDB oder komplexer - CouchDB, die Schlüssel-Wert-Paare enthält, zum Beispiel: Vorname - Ivan, Nachname - Ivanov, Datum der Registrierung im System - 12.12.21, Geburtsdatum - 17.12.1961, usw. WorldState und die verteilte Registrierung müssen mit allen Mitgliedern dieses Kanals übereinstimmen.
Da Hyperledger Fabric ein Netzwerk ist, in dem alle Teilnehmer bekannt und authentifiziert sind, wird hier eine dedizierte Zertifizierungsstelle - CA (Certification Authority) - verwendet. CA arbeitet auf der Basis des X.509-Standards und der Public-Key-Infrastruktur - PKI.
Der Mitgliedschaftsdienst ist ein Dienst, über den Teilnehmer das Eigentum an einem Objekt in einer bestimmten Organisation oder einem bestimmten Kanal überprüfen.
Eine Transaktion ist in den meisten Fällen eine Aufzeichnung neuer Daten in einer verteilten Registrierung.
Es gibt auch Transaktionen zum Erstellen von Kanälen oder intelligenten Verträgen. Die Transaktion wird von der Benutzeranwendung initiiert und endet mit einem Datensatz in der verteilten Registrierung.
Ein Kanal ist ein geschlossenes Subnetz, das aus zwei oder mehr Teilnehmern eines Blockchain-Netzwerks besteht und vertrauliche Transaktionen innerhalb eines begrenzten, aber bekannten Teilnehmerkreises durchführen soll. Der Kanal wird von den Teilnehmern, seiner verteilten Registrierung, intelligenten Verträgen, dem Bestellservice und WorldState definiert. Jedes Channel-Mitglied muss berechtigt sein, auf den Channel zuzugreifen, und das Recht haben, verschiedene Arten von Transaktionen durchzuführen. Die Autorisierung erfolgt über den Mitgliederservice.
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, mit dem Studenten, die an Universitäten studieren, registriert und aufgezeichnet werden können. Unser Netzwerk besteht aus zwei Organisationen, die zu Universität A und Universität B gehören. Jede Organisation enthält eine Client-Anwendung sowie deren Committing and Endorsing Peer. Wir nutzen auch den Bestellservice für gemeinsame Dienste, den Mitgliederservice und die Zertifizierungsstelle.
1) Transaktionsinitiierung
Die Benutzeranwendung initiiert mithilfe des Hyperledger Fabric SDK eine Transaktionsanforderung und sendet eine Anforderung an Knoten mit intelligenten Verträgen. Die Anforderung kann zum Ändern oder Lesen aus einer verteilten Registrierung (Ledger) sein. Wenn wir ein Beispiel für unsere Testkonfiguration eines Systems für Studenten der Buchhaltung betrachten, sendet die Clientanwendung eine Transaktionsanforderung an die Knoten der Universitäten A und B, die in der Endorsement-Richtlinie des so genannten Smart Contract enthalten sind. Knoten A ist ein Knoten an einer Universität, der einen ankommenden Studenten registriert, und Knoten B ist ein Knoten an einer anderen Universität. Damit die Transaktion in einer verteilten Registrierung gespeichert werden kann, müssen alle Knoten, die gemäß der Geschäftslogik die Transaktion genehmigen müssen, intelligente Verträge mit demselben Ergebnis erfolgreich abschließen. Der Knoten Eine Benutzeranwendung, die die Hyperledger Fabric SDK-Tools verwendet, empfängt eine Endorsement-Richtlinie und ermittelt, an welche Knoten eine Transaktionsanforderung gesendet werden muss. Dies ist eine Anforderung zum Aufrufen eines bestimmten Smart-Vertrags (Chaincode-Funktion) zum Lesen oder Schreiben bestimmter Daten in eine verteilte Registrierung. Technisch gesehen verwendet das Client-SDK die entsprechende Funktion, deren API ein Objekt mit Transaktionsparametern übergibt, fügt auch die Client-Signatur hinzu und sendet diese Daten über den Protokollpuffer über gRPC an die entsprechenden Knoten (Endorsing Peers).
Bild 2. Transaktionsinitiierung
2) Erfüllung eines intelligenten Vertrags
Die Knoten (Endorsing Peers), die eine Anfrage für eine Transaktion erhalten haben, überprüfen die Client-Signatur und nehmen, wenn alles in Ordnung ist, ein Objekt mit den Anforderungsdaten und starten mit diesen Daten die Simulation der intelligenten Vertragsausführung (Chaincode-Funktion). Ein intelligenter Vertrag ist eine Geschäftstransaktionslogik, eine Reihe von Bedingungen und Anweisungen (in unserem Fall handelt es sich um die Bestätigung eines Schülers, dies ist ein neuer Schüler oder ist er bereits registriert, eine Altersüberprüfung usw.). Um einen intelligenten Vertrag auszuführen, benötigen Sie auch Daten von WorldState. Als Ergebnis der Simulation des Smart Contract auf Endorsing Peer werden zwei Datensätze erhalten - Read Set und Write Set. Der Lesesatz und der Schreibsatz sind die ursprünglichen und neuen Werte von WorldState. (neu - im Sinne der Simulation eines Smart Contract).
Bild 3. Ausführung eines intelligenten Vertrags
3) Rückgabe von Daten an die Clientanwendung
Nach der Simulation des Smart-Vertrags gibt Endorsing Peers die Anfangsdaten und das Simulationsergebnis sowie das mit ihrem Zertifikat signierte RW-Set an die Client-Anwendung zurück. Zu diesem Zeitpunkt werden keine Änderungen an der verteilten Registrierung vorgenommen. Die Clientanwendung überprüft die Signatur des Endorsing Peer und vergleicht auch die Quelldaten der gesendeten Transaktion mit den zurückgegebenen Daten (dh, sie prüft, ob die Quelldaten, auf denen die Transaktion simuliert wurde, verzerrt sind). Wenn die Transaktion nur zum Lesen von Daten aus der Registrierung diente, erhält die Clientanwendung dementsprechend den erforderlichen Lesesatz, und dies schließt die Transaktion normalerweise erfolgreich ab, ohne die verteilte Registrierung zu ändern. Bei einer Transaktion, die Daten in der Registrierung ändern soll, überprüft die Clientanwendung zusätzlich die Implementierung der Endorsing-Richtlinie. Es ist möglich, dass die Clientanwendung das Ergebnis der Endorsement-Richtlinie nicht überprüft. In diesem Fall bietet die Hyperledger Fabric-Plattform jedoch die Überprüfung von Richtlinien für Knoten (Comitting Peers) beim Hinzufügen einer Transaktion zur Registrierung.
Bild 4. Rückgabe von Daten an die Clientanwendung
4) Senden von RW-Sets an Ordering Peers
Die Client-Anwendung sendet die Transaktion zusammen mit den zugehörigen Daten an den Bestellservice. Dies umfasst das RW-Set, Endorsing Peers und die Kanal-ID.
Bestellservice - Basierend auf dem Namen besteht die Hauptfunktion dieses Service darin, eingehende Transaktionen in der richtigen Reihenfolge zu erstellen. Ebenso wie die Bildung eines neuen Blocks der verteilten Registrierung und die garantierte Lieferung neu gebildeter Blöcke an alle Commiting-Knoten, wodurch die Konsistenz der Daten auf allen Knoten sichergestellt wird, die die verteilte Registrierung enthalten (Commiting-Peers). Gleichzeitig ändert der Bestellservice selbst die Registrierung in keiner Weise. Der Bestellservice ist eine wichtige Komponente des Systems und besteht daher aus mehreren Knoten. Der Bestellservice überprüft die Transaktion nicht auf Gültigkeit, sondern akzeptiert die Transaktion einfach mit einer bestimmten Kanal-ID, ordnet eingehende Transaktionen in einer bestimmten Reihenfolge an und bildet daraus neue Blöcke der verteilten Registrierung. Ein Bestellservice kann mehrere Kanäle gleichzeitig bedienen. Der Bestellservice enthält einen Kafka-Cluster, der die korrekte (unveränderte) Transaktionswarteschlange unterstützt (siehe Abschnitt 7).
Bild 5. Senden von RW-Sets an Ordering Peers
Die im Bestellservice gebildeten Blöcke werden an alle Netzwerkknoten übertragen. Jeder Knoten, der einen neuen Block erhalten hat, überprüft die Konformität mit der Endorsing Policy, überprüft, ob alle Endorsing Peers das gleiche Ergebnis (Write Set) als Ergebnis der Simulation eines Smart Contract erhalten haben, und prüft auch, ob sich die ursprünglichen Werte geändert haben (d. H. - Read Set - Daten, die von einem intelligenten Vertrag von WorldState gelesen wurden), seit die Transaktion initiiert wurde. Wenn alle Bedingungen erfüllt sind, wird die Transaktion als gültig markiert, andernfalls erhält die Transaktion einen ungültigen Status.
Bild 6. Formblöcke an Committing 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 WorldState (aktueller Status) angewendet. Dementsprechend werden neue Werte der Objekte aufgezeichnet, die von der Transaktion betroffen waren. Wenn die Transaktion ein Token erhalten hat - ungültig (z. B. zwei Transaktionen mit denselben Objekten innerhalb desselben Blocks), stellt sich heraus, dass eine der Transaktionen ungültig ist, da die Anfangswerte bereits von der anderen Transaktion geändert wurden. Diese Transaktion wird auch der verteilten Registrierung mit einem ungültigen Token hinzugefügt. Der Schreibsatz dieser Transaktion gilt jedoch nicht für den aktuellen Status von WorldState und ändert dementsprechend die an der Transaktion beteiligten Objekte nicht. Danach wird eine Benachrichtigung an die Benutzeranwendung gesendet, dass die Transaktion für immer zur verteilten Registrierung hinzugefügt wird, sowie der Status der Transaktion, dh ob sie gültig ist oder nicht ...
Bild 7. Hinzufügen eines Blocks zur Registrierung
BESTELLSERVICE
Der Bestellservice besteht aus einem Kafka-Cluster mit den entsprechenden ZooKeeper-Knoten und Bestelldienstknoten (OSN), die sich zwischen den Bestellservice-Clients und dem Kafka-Cluster befinden. Kafka Cluster ist eine verteilte, fehlertolerante Flow-Management-Plattform (Messaging). 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). Eine Illustration der Struktur des Themas ist unten angegeben. Es ist diese Eigenschaft von Kafka, die zum Erstellen der Blockchain-Plattform verwendet wird.
entnommen aus kafka.apache.org
Bild 8. Struktur des Bestelldienstes
Nützliche Links
Youtube - Aufbau einer Blockchain für das Geschäft mit dem Hyperledger-Projekt
Hyperledger Fabric Docs
Hyperledger Fabric: Ein verteiltes Betriebssystem für berechtigte Blockchains
Danksagung
Ich bedanke mich bei meinen Kollegen für die Hilfe bei der Vorbereitung des Artikels:
Nikolay Marina
Igor Hapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Kurdenkova
Ekaterina Guseva