Hyperledger Fabric v2.0: Blockchain-Entwicklungen mit modularem Konsens

Aktualisiert: 23. September 2024 Wissen

Blockchain-Entwicklungen auf der Hyperledger Fabric 2.0 Enterprise-Blockchain mit modularem Konsens und Chaincode-Lifecycle-Managment für Unternehmen.

Ein Meilenstein auf dem Weg zu standardisierten Blockchain-Entwicklungen mit hoher Interoperabilität, verbessertem Datenschutz und noch mehr Leistung.

Im zweiten Teil blicken wir detaillierter in die Architektur des Protokolls und der daraus resultierenden Möglichkeiten für Enterprise Blockchain-Entwicklungen. Wer Teil 1 zu Hyperledger Fabric 2.0 verpasst hat, kann den Artikel hier nachlesen.

Blockchain-Entwicklungen mit Datenschutz

Das Konzept von Hyperledger Fabric basiert auf Kanälen, mit denen teilnehmende Organisationen sich zusammenschließen und miteinander kommunizieren können.

Im Netzwerk sind mehrere Ledger vorhanden, die Hauptbücher oder Kanäle (Channels). Personen, die Berechtigung für die Teilnahme am Kanal haben, können die verknüpften Transaktionen und Informationen auf einem Kanal sehen.

Eine Organisation kann gleichzeitig Mitglied in mehreren Kanälen sein. Es ist auch möglich, dass eine Organisation mehrere Kanäle betreibt.

Dies macht vor allem hinsichtlich von Datenschutz und Privatsphäre-Einstellungen Sinn, denn so sind Geschäftsvorfälle und Informationen nur einem speziellen Kreis von Benutzern zugänglich.

Blockchain-Entwicklungen lassen sich noch leichter implementieren und können bezüglich des Umgangs mit vertraulichen Daten im Unternehmens-Ledger für mehr Sicherheit und Privatsphäre sorgen.

Verbinden sich mehrere Kanäle, spricht man von einem Unternehmens-Netzwerk. Sie bieten eine effiziente und gemeinsame Nutzung der Infrastruktur unter Wahrung des Datenschutzes und die leichte Implementierung von Blockchain-Entwicklungen.

Bei Bedarf können Channels gemeinsame Aktivitäten koordinieren. Aber sie sind gleichzeitig auch unabhängig genug, um die Arbeiten der teilnehmenden Organisationen im Channel zu trennen.

Alle Channel Mitglieder führen Smart Contracts erst dann aus, wenn der Blockchain-Entwickler die notwendigen Chaincodes definiert hat.

Sie enthalten die Funktionsweisen und die notwendigen Parameter zum Ausführen von Smart Contracts. Blockchain-Entwickler, die gerade unter der Krise leiden, erhalten übrigens finanzielle Hilfe durch die EU.

Ein Kanal ist ein vollkommen separater Kommunikationsweg zwischen einer Reihe von Organisationen und beinhaltet eine unabhängige Blockchain, die als World State den aktuellen Zustand des Haupt-Ledgers widerspiegelt.

Jeder Kanal hält eine Kopie des World State auf dem Peer, allerdings kann ein Kanal auch mehrere Peers enthalten. Smart Contracts lassen sich immer pro Channel verwalten.

Es handelt sich dabei um digitale Verträge für alle kundenbezogenen Blockchain-Entwicklungen.

Definition von Hyperledger Fabric Channels

Teilnehmende Organisationen
Anker-Peers pro Mitglied, die Transaktionen vorschlagen und empfangen
Gemeinsam genutztes Hauptbuch (Ledger)
Chaincode-Anwendungen
Ordering Service Node(s)
Dynamische Funktion und Möglichkeit der Neukonfiguration
Hinzufügen von neuen Kanälen durch Blockchain-Entwicklungen im laufenden Betrieb

Jede Partei muss authentifiziert und autorisiert sein, um auf einem Kanal Transaktionen durchführen zu können. Beim Eintritt eines neuen Mitglieds in das Netzwerk erhält dieser eine eigene Identität, die vom Membership Service Provider vergeben wird.

Anschließend prüft jeder Peer im Netzwerk die Übereinstimmung der Identität der Peers und Dienste auf dem Kanal.

Jeder neue Kanal löst eine Anforderung für einen Genesis-Block aus, der auf dem Kanal-Ledger liegt und alle Richtlinien zu Mitgliedern und Peers enthält. Neue Mitglieder werden dann wiederum über diesen Genesis-Block freigegeben.

In jedem Kanal gibt es einen Leader-Peer, der im Namen des Mitglieds mit dem Bestelldienst kommuniziert. Fehlt dieser definierte Leader, wird ggf. ein mathematischer Algorithmus eingesetzt, der einen solchen Leader-Peer definiert. Der Konsensus-Bestelldienst bestellt Transaktionen und liefert sie in einem Block an jeden führenden Peer.

Dieser Leader-Peer verteilt dann den Block an die Mitglieder im Kanal. Es ist mit den sogenannten Anchor-Peers nicht möglich, dass Ledger-Daten von einem Kanal zu einem anderen gelangen.

Sie können mehreren Kanälen angehören und daher auch mehrere Ledger verwalten. Plug-in Blockchain-Entwicklungen im neuesten Update versprechen noch mehr Flexibilität beim Channel-Management.

Configtx-Datei zum individuellen Konfigurieren

Vertrauliche und private Transaktionen sind im Netzwerk durch die Isolierung von Peers und Ledgers möglich, denn sie sind nach Kanälen getrennt ans Blockchain-System angeschlossen.

Pro Kanal existiert eine Sammlung aus Konfigurationsdateien. Sie verwenden die Bezeichnung configtx und haben die folgenden wichtigen Eigenschaften:

Jedes Element der Konfiguration in einer Blockchain-Entwicklung mit Hyperledger Fabric 2.0 ist einer Version zugeordnet, die bei jeder Änderung erweitert wird.
Jede festgeschriebene Konfiguration enthält eine Sequenznummer.
Jedem Element der Konfiguration ist eine Richtlinie zugeordnet. Diese regelt, ob Änderungen an dem Element zulässig sind oder nicht.
Anhang der Richtlinien kann jeder die Kopie der vorherigen Konfigurationsdatei, auch wenn diese keine zusätzlichen Informationen enthalten, überprüfen und feststellen, ob sie den gültigen Richtlinien entspricht.
Es existieren Root-Konfigurationsdateien, die hierarchisch angeordnete Untergruppen beinhalten. Jeder Untergruppe sind Werte und Richtlinien zugeordnet.
Channel Konfigurationstransaktionen wirken sich eher auf Metadaten aus, als auf die aktuellen Daten im Hauptbuch.
Die configtx Dateien liegen in derselben Blockchain wie die normalen Transaktionen
Der Genesis-Block enthält die Konfigurationsdateien eines Kanals, einschließlich der Informationen des Bestellers, die für den Konsensmechanismus notwendig sind.
Derzeit wird jede Kanalaktualisierung mittels configtx manuell ausgeführt; denkbar ist aufgrund der Systemarchitektur aber auch eine zukünftige Automatisierung des Prozesses.
Das Verwalten von Kanälen berührt bei Hyperledger Fabric wichtige Aspekte hinsichtlich der Struktur der Blockchain-Plattform.

Aufbau der Fabric Architekturebenen

Die Blockchain-Ebene beschäftigt sich mit der Zusammenarbeit der Stakeholder im Netzwerk und in diesem Zusammenhang mit dem Erstellen und/oder dem Einrichten von Regeln und Richtlinien. Die Aufgabe besteht in der Implementierung eines Peer-to-Peer-Protokolls, damit die beteiligten Knoten über das Internet auf der Blockchain miteinander kommunizieren können. Auf dieser Ebene lassen sich verschiedene Konsensprotokolle aufsetzen, wie Proof-of-Work oder PBFT. Mit kryptographischen Tools werden Schlüssel, sichere Identitäten und Rollen erstellt. Diese Ebene nutzt die spezielle Besteller-Funktion, um die Kommunikation zwischen Peers und die Verarbeitung von Datentransaktionen zu erleichtern. Für die Arbeit mit dieser Ebene bedarf es Blockchain-Entwickler mit tiefgehenden Kenntnissen in Unix/Linux/Ubuntu, Docker (einem Deploymentmodell von Hyperledger Fabric) oder vergleichbaren Betriebssystemen. Es ist zwar eine komplexe Tätigkeit im Rahmen einer Blockchain-Entwicklung, sie benötigt jedoch nur wenig Programmierkenntnisse. Wichtige Keywords sind: Konsensmechanismus, Ledger und Peer-to-Peer.
Die sogenannten Chaincode Ebene wird in einer von drei Programmiersprachen verfasst. Kenntnis mindestens einer dieser drei Sprachen ist für Blockchain-Entwickler für diesen Prozess notwendig. Außerdem wäre es empfehlenswert, sich mit der effektiven Verwendung von CLI- und Docker-Befehlen vertraut zu machen. Wichtige Unix/Linux/Ubuntu-Kentnisse sind an dieser Stelle jedoch ein Muss. Hier werden die System-Chaincodes und die User-Chaincodes erstellt. Sie gewährleisten, dass der Chaincode, die Smart Contracts sicher ausgeführt werden. Grundsätzlich ist das Protokoll offen, auch andere Programmiersprachen und Umgebungen können integriert werden. Wichtiges Keyword: Container.
Membership Ebene mit webbasierter oder mobiler Applikation ermöglicht die Integration der zweiten Ebene in die dritte Ebene. Der Chaincode liegt auf der mittleren Ebene der Hyperledger Blockchain-Plattform und kann mittels Fabric API oder Composer API mit der dritten Ebene des Endnutzers verbunden werden. Über verschiedene weitere Entwickler-Schritte steht am Ende dem Endkunden der Zugang zu seinem Netzwerk auf Hyperledger Fabric 2.0 zur Verfügung. Wichtige Keywords sind: Registrierung und Identität.

User-Chaincodes haben vier Lebenszyklen

Install= Installieren ordnet dem Kettencode einen Ort oder Pfad zu, sodass er bei Bedarf gefunden und verwendet werden kann.
Instantiate= Instanziieren bedeutet das Erstellen eines Docker-Container-Image, um alle zukünftigen Aufrufe und Abfrageanforderungen des jeweiligen Chaincodes zu unterstützen. Instanziieren steht in der Programmierung für das Erzeugen eines konkreten Objektes einer bestimmten Klasse.
Invoke= Aufrufen steht für das einfache Einfügen und Schreiben von Chaincodes oder dem Einfügen der Daten auf der Blockchain.
Query= Abfragen ermöglicht das Abrufen und Erhalten von Daten aus der Blockchain

Speziell in Produktionsumgebungen ist es möglich, dass Schritt 1 und 2 zu einem einmaligen Prozess zusammenschmelzen.

Denn sobald ein bestimmter Chaincode installiert und instanziiert wurde, ist er immer für jede zukünftige Anwendung und Verwendung verfügbar.

Chaincodes werden entweder per Befehl „Peer“ an der CLI-Eingabeaufforderung installiert oder über den Fabric REST-API-Server, was als überaus leicht gilt.

Mehrstufiger Konsens auch als Plug-in Modul

Im Fabric-Konsens werden zur Überprüfung verschiedene mehrstufige und hierarchisch angeordnete Ebenen durchlaufen.

Die Berechtigungen, die Bestätigung, die Datensynchronisation aller Teilnehmer, die Transaktionsreihenfolge und die Richtigkeit der Änderungen werden sichergestellt, bevor die Transaktion in den Haupt-Ledger übertragen wird.

Der auf Berechtigungen basierende Konsens geht davon aus, dass allen Teilnehmern im Netzwerk teilweise vertraut wird und läuft grundsätzlich in drei Phasen ab:

1. Phase: Die Bestätigung (Endorsment): Ein Peer entscheidet auf Basis des Chaincode, ob die Transaktion gültig ist.
2. Phase: Die Bestellung (Ordering): Eine Sequenz von Transaktionen wird erzeugt und in Blöcke verpackt.
3. Phase: Die Validierung (Validation): Jeder Peer prüft vor der finalen Validierung, ob das Endorsment eingehalten wurde und die Parallelität (Concurrency) zur Vermeidung von doppelter Buchhaltung korrekt sind.

Ordering und Validation Prozess getrennt

Hyperledger hat seine Business-Blockchain so aufgebaut, dass der Konsens in zwei separaten Schichten abläuft. Zuerst erfolgt das Ordering, dann die Validation.

Beide Schritte sind logisch voneinander getrennt und ermöglichen so, dass jedes Hyperledger Framework mit jedem Hyperledger Konsensmechanismus zusammenarbeiten kann.

Im Ordering Service von Hyperledger Fabric arbeitet man mit dem Kafka-Konsens. Blockchain-Entwicklungen sind damit deutlich leichter auch über verschiedene Frameworks hinweg möglich.
Der Kafka-Konsens definiert Leader und nur diese Leader dürfen Bestellungen ausführen. Als Leader können dabei nur synchrone Repliken im Netzwerk bestimmt werden. Bei diesen handelt es sich um replizierte Datenbanken, bei der die Aktualisierung der Repliken (Kopien) synchron (parallel) durchgeführt werden.
Bei den Ledgers in jedem Channel handelt es sich um genau ein solches synchron aktualisiertes Hauptbuch. Ausgeführt wird der Konsens innerhalb von Sekunden und bietet eine Toleranz gegen Absturzfehler.
Nur synchrone Systeme bieten diese Toleranz vor einem Systemabsturz, bei dem der gerade laufende Prozess unterbricht und aussetzt. Allerdings ist Kafka nicht tolerant gegen byzantinische Fehler. Dabei handelt es sich um Fehler in der Programmierung, bei denen sich ein System beliebig falsch verhalten kann. Das schwer zu fassende Fehlermodell beschreibt ein Problem der Übereinkunft von Komponenten in einem System. Die Einstimmigkeit ist hierbei nicht gegeben, der Konsens kann also nicht erfüllt werden.

Raft ersetzt Apache Kafka

In der Version Hyperledger Fabric 2.0 ist nun der ab Version 1.4.1 vorgestellte Konsensmechanismus Raft der empfohlene Konsens-Service. Die Abhängig zum externen Apache Kafka Cluster ist weggefallen. Das macht den Ordering-Service (Bestellvorgang) zum maßgeblichen dezentralen Verwaltungsmodell, das mehrere Bestellorganisationen bereitstellen können.

In diesem Verfahren kann außerdem ein Orderer (Bestellknoten) jetzt auswählen, welche Kanäle (Channels) er bedienen soll, anstatt alle Kanäle gemäß der bisherigen Anforderung zu bedienen.

Damit wird eine wichtige Verbesserung der Skalierbarkeit erreicht, mit der eine große Anzahl von Kanälen und Transaktionen besser unterstützt wird. Außerdem optimiert er damit die Datenschutz-Richtlinien.

Das Endorsmentmodell zur Erzielung von Konsens zwischen den Transaktions-Organisationen ist überaus flexibel und umfasst auch die Transaktionsreihenfolge und die Blockverteilung. Das sogenannten „pluggable consensus protocol“ ab Version 2.0 ermöglicht, die Plattform effektiv an bestimmte Anwendungsfälle und Vertrauensmodelle (Konsens) anzupassen.

Je nach Art der Organisation kann ein fehlertoleranter byzantinischer Konsens (Byzantine Fault Tolerance BFT) nötig oder unnötig sein, ebenso wie ein fehlertoleranter Crash Konsens (Crash Fault Tolerance CFT) nicht überall gewünscht wird oder als passend empfunden wird.

Der BFT Konsens ist weitaus komplexer und wird vor allem in Systemen angewendet, bei denen man davon ausgehen muss, dass auch nicht vertrauenswürdige Teilnehmer im Netzwerk vorhanden sind.

Wenn verschiedene Teile des Netzwerks dadurch beispielsweise unterschiedliche Blockchain-Zustände haben, dann können sie nicht weiter im selben Netzwerk zusammenarbeiten.

Die Blockchain wird daher auch gerne als „Quelle der Wahrheit“ bezeichnet. Mit den jetzt integrierten „pluggable“ Konsensverfahren unter Hyperledger Fabric 2.0 können Organisationen genau den Konsensalgorithmus implementieren, der zu ihrer Anwendung passt.

In der Dokumentation für Blockchain-Entwickler finden sich Begriffe wie distributed consensus oder decentralized consensus.

Modulare Blockchain-Plattform bietet Flexibilität

Im modularen Aufbau der Blockchain-Plattform Hyperledger Fabric v2.0 liegt das Grundprinzip einer einfach zu verwendenden Programmierschnittstelle API zugrunde.

Gemäß der Design-Philosophie von Hyperledger ist der modulare Aufbau erweiterbar. Das schließt auch den Konsens ein, wie bereits weiter oben im Text beschrieben.

Der Grundsatz der Open-Source-Plattform bleibt dabei aber stets unverändert und beinhaltet:

Modulares Systems
Interoperabilität
Sichere Lösungen
Ohne native Kryptowährung
Leicht zu verwendenden API

Die Hyperledger Working Group WG nennt im offiziellen Überblick der Hyperledger Blockchain Dokumentation folgende Komponenten zu den wesentlichen Bestandteilen der Framework-Architektur:

Der Konsens ist verantwortlich für die Vereinbarung über die Bestellung (Orderer) und Bestätigung der Richtigkeit einer Gruppe von Transaktionen
Smart Contracts verarbeiten die Transaktionsanforderungen und Bestimmungen gemäß der Geschäftslogik (Endorsment-Richtlinie) die Gültigkeit einer Transaktion.
Das Peer-to-Peer-Netzwerk dient dem Nachrichtentransport zwischen Nodes (Peers), die am gemeinsam genutzten Ledger teilnehmen.
Datenspeichermodule erleichtern die Interoperabilität und gewähren eine geschützte Atmosphäre für den Datenschutz.
Kryptographie ermöglicht den Austausch verschiedener kryptografischer Algorithmen
Root-of-Trust Modul als vertrauenswürdige Instanz bietet kryptografische Sicherheit und ermöglicht das Generieren von digitalen Signaturen. Kann auch Authentifizierungs- und Autorisierungsprozesse übernehmen.

Blockchain-Framework Fabric auch für Supply-Chain

Hyperledger Fabric v2.0 ist die nächste Generation der Enterprise-Blockchains und bietet zahlreiche spannende Veränderungen nicht nur für Blockchain-Entwickler.

Seit dem Start hat sich Hyperledger Fabric zu einem der beliebtesten Blockchain-Frameworks für Unternehmen entwickelt. Große IT-Unternehmen wie IBM, AWS, Google, Oracle, Alibaba und andere setzen die Lösungen bereits ein.

Mit dem Eintritt von Walmart in die Linux-Foundation will man sich auch verstärkt dem Thema Supply-Chain mithilfe des Blockchain-Frameworks widmen.

Im Jahr 2019 verwendeten bereits 30 der 50 erfolgreichsten Unternehmen der Welt (laut Forbes-Liste) Hyperledger Fabric. Das neueste Produkte-Release gilt als weiterer Meilenstein auf dem Weg zum Blockchain-Standard für Unternehmen.

Als Open-Source-Plattform ist in die neuesten Blockchain-Entwicklungen auch wieder zahlreiches Feedback der Endkunden eingeflossen.

Wert wurde aber auch auf die anwenderfreundlichere Benutzung der Enterprise-Blockchain gelegt und eine Leistungsverbesserung erreicht.

Entscheidungen über die technischen Neuerungen und darüber, welche Vorschläge am Ende in das Release einfließen, obliegt allein der Linux-Stiftung und dem Team aus Chef-Entwicklern.

Umgesetzt werden diese allerdings von den Open-Source Blockchain-Entwicklern rund um den Globus.

DLT für Konsortium-Blockchains geeignet

Hyperledger Fabric 2.0 ist ein Framework der neuesten Generation und für Unternehmen entwickelt, die die Vorteile eines verteilten Hauptbuches, der Distributed-Ledger-Technologie, für ihre Prozesse nutzen möchten.

Vor allem der Einsatz in Produktionsumgebungen hat die Entwicklergemeinde im Blick, denn die Adaptierungen finden derzeit nur in den Finanzunternehmen der Vereinigten Staaten statt.

Im neuesten Release gibt es genau wie in der Vorgängerversion die Möglichkeit, einzelne Netzwerkkomponenten nach eigenen Bedürfnissen zu konfigurieren und noch besser individuellen Geschäftsprozessen anzupassen.

Funktionen lassen sich nach Bedarf über programmierbare Blockchain-Entwicklungen aktivieren.

Viele davon sind bereits vor-installiert und bieten viel Flexibilität für Unternehmen-Anwendungen auf der Hyperledger Fabric 2.0 Plattform.

IBM freut sich über diesen wichtigen Meilenstein im Entwicklungslebenszyklus von Hyperledger Fabric. Wir sind stolz darauf, Teil der Community zu sein, die an ihrer Entwicklung mitgearbeitet hat, und wir sind bestrebt, IBM Blockchain Plattform – die branchenweit erste Multi-Cloud-Implementierung von Hyperledger Fabric – zu aktualisieren, um die neuen Funktionen und die verbesserte Leistung in dieser Meilensteinversion zu nutzen. Jerry Cuomo, IBM Fellow und VP der Blockchain Platform, IBM, (aus dem Englisch übersetzt), Quelle

Das bietet das neue Hyperledger Fabric v2.0

Smart Contracts erhalten eine dezentrale Governance Einheit, die den Parteien mehr Flexibilität bietet. Während es in den früheren Versionen nur einer Organisation möglich war, Smart Contracts einzurichten und die notwendigen Parameter dafür zu definieren, lassen sich ab sofort über das neue Chaincode-Lifecycle-Managment die Prozesse über Blockchain-Entwicklungen dezentral steuern. Damit einigen sich mehrere Parteien im Vorfeld auf die Parameter für die Endorsment-Richtlinie.
Persönliche Interessen lassen sich besser schützen, bevor eine Einigung erzielt ist und die Interaktion mit dem Ledger beginnt. Das neue Management-Tool unterstützt aber nicht nur das neue dezentrale Modell, sondern auch die vorherigen des zentralisierten Vertrauensmodells.
Die Need-to-Know Basis erlaubt die Freigabe von Daten nur für bestimmte Mitglieder in einem Channel. Unternehmen können in Version 2.0 wählen, welche Daten sie preisgeben möchten, während sie die Gültigkeit geheimer Daten durch kryptografische Mechanismen sicherstellen.
Das Aktualisieren eines Chaincodes ist nur möglich, wenn eine ausreichende Anzahl von Organisationen dem Upgrade zustimmt. Firmengeheimnisse werden gewahrt, da die Anzahl von Nodes, die auf die Daten zugreifen können, schon im Vorfeld begrenzt ist.
Zusätzlich können Daten innerhalb eines Ledgers absolut vertraulich behalten werden, da sie nur für bestimmte Nodes freigegeben werden. Die Datentransparenz ist gewährleistet, ohne dass das Erstellen neuer Channels notwendig ist.
Mittels privater Hashes lassen sich die privaten Datentransaktionen verfolgen und überwachen. Private Datensammlungen sind jetzt optional als eine Endorsment-Richtlinie definierbar. Diese Funktion schränkt ein, welche Organisationen Daten in eine Sammlung schreiben dürfen.
Dieselben dezentralen Methoden zur Einigung (Endorsment), die dem neuen Chaincode-Lifecycle-Managment zugrunde liegen, können auch in Unternehmens-Chaincodes verwendet werden. Damit ist sichergestellt, dass Unternehmen Datentransaktionen zustimmen, bevor sie in das Hauptbuch kommen. Eine automatisierte Überprüfung der Chaincodes lässt sich, wie bereits weiter oben erklärt, ebenfalls leicht als Blockchain-Entwicklung programmieren.

Standard-Protokoll für Business-Blockchains

Anders als im Pre-Announcement Ende 2019 angekündigt, ist das Projekt FabToken nicht im neuesten Update enthalten. Damit wäre die Generierung von Krypto-Coins ähnlich dem ERC20-Token möglich gewesen.

Über die Gründe dafür gibt es seitens der Linux Foundation nur wenig befriedigende Antworten. Darunter die, dass sich durch die Art und Weise, wie sich FabToken im Netzwerk implementiert, einige grundlegende Probleme aufgetan haben.

Aber das sind nur kleine Hindernisse, denn in der Blockchain-Community ist Hyperledger Fabric 2.0 mit großem Interesse aufgenommen worden.

Hyperleder Fabric ist auf dem besten Weg, das neue Standard-Protokoll für Enterprise Blockchain-Entwicklungen zu werden und beginnt gerade erst mit der Integration von DTL-Lösungen außerhalb des Finanzsektors.

Blockchain Hyperledger