Ein Überblick über die Hyperledger-Blockchain-Projekte [blockcentric #7]

Das Projekt Hyperledger ist ein Zusammenschluss der Linux Foundation, in dem es um Blockchain-Implementierungen und Tools geht. Dabei liegt der Fokus vor allem auf privaten und permissioned Blockchain-Systemen. Das Projekt wurde Ende 2015 gestartet und erregte schnell die Aufmerksamkeit einiger großer Firmen, die schon früh im Bereich der Distributed-Ledger-Technologien aktiv waren. Daraus sind einige Projektvorschläge entstanden, die seit 2016 als Incubators angenommen wurden. Meist wurde mit den jeweiligen Proposals schon eine existierende Codebasis eingereicht. So auch die bekannten Projekte Fabric und Sawtooth.

Heute besteht das Projekt Hyperledger aus einer sehr aktiven Community. Über 220 Organisationen unterstützen die Initiative mittlerweile. In den größten Projekten zählen wir über 100 Contributors sowie jeweils zirka 5000 Commits. Unter Blockchain-Enthusiasten hat das Projekt bereits jetzt einen hohen Stellenwert.

Die Hyperledger-Unterprojekte

Doch was steckt hinter den zu Hyperledger gehörenden Projekten? Für welche Anwendungsfälle sind sie gedacht? Diese Fragen stellen sich in letzter Zeit vor allem Leute, die sich beispielsweise über die Website über das Thema schlau machen wollen. Die Projekte werden dort nur sehr grob angeschnitten. Zum Verständnis muss man sich durch viel, teils sehr technische, Dokumentation suchen. Einige Lösungen sind zudem unzureichend dokumentiert, werden aber dennoch in Berichten über interessante Projekte genannt und wecken somit unser Interesse.

Wir betrachten einmal grob die Namen Fabric , Sawtooth ,Burrow , Indy und Iroha . Diese treten in Verbindung mit fundamental unterschiedlichen Implementierungsansätzen für Blockchain-Lösungen auf. Auch auf die Projekte, die Tools für das Ökosystem bauen, gehen wir kurz ein. Hier gibt es Composer ,Explorer sowie Cello .

Fabric – Der flexible Ansatz

Fabric ist das aktivste der Projekte und ist gleichzeitig am stärksten darauf ausgelegt, für alle möglichen Blockchain-Anwendungsfälle genutzt werden zu können. Es war das erste der Projektvorschläge, die aus dem Incubator-Status zu einem aktiven Projekt wurden. Die aktuellste Version 1.0 wird als stabil bezeichnet und Version 1.1 steht mit vielen Verbesserungen bereits in den Startlöchern.

Die Fabric-Plattform ist so flexibel, da alle Komponenten als „Plug and Play“ bezeichnet werden. Fabric bildet eine Organisationsstruktur ab, die aus beliebig vielen Organisationen besteht. Alle davon betreiben Netzwerk-Knoten, sogenannte Peers. Die Peer-Knoten können unterschiedliche Rollen einnehmen, somit können Netzwerke nach Bedarf orchestriert werden. Außerdem kann der Konsens-Algorithmus frei bestimmt werden. Ebenfalls die Rolle der Certificate Authorities im Netzwerk kann durch unterschiedliche Implementierungen erfüllt werden. Für die Erfüllung unterschiedlicher Bereiche der Privatsphäre im Netzwerk können Channels erstellt werden . Alle Organisationen und Teilnehmer sind überlicherweise zusammen in einem großen Channel. Wenn eine Organisation jedoch private Transaktionen mit einer weiteren abwickeln muss, kann mit Channels eine Art Subnetz angelegt werden. Auf Channels kann bei Bedarf vollkommen individueller Code deployed werden. Letztendlich hat man besonders in der Implementierung der Geschäftslogik die meisten Freiheiten. Der Code der dazu da ist und individuell in die Channels installiert werden kann, wird Chaincode genannt und kann in Go, Node.js oder Java entwickelt werden.

„Fabric ist der Großvater der anderen Projekte“, so Brian Behlendorf (Executive Director von Hyperledger, ebenfalls bekannt für den Apache Webserver sowie die Gründung der Apache Software Foundation).

Sawtooth – Vertrauen in Software Guard Extensions

Sawtooth ist ebenfalls ein bereits aktives Projekt und seit Januar 2018 auch in der stable Version 1.0 verfügbar. Es schmückt sich ebenfalls mit einer modularen Architektur, die private Blockchain-Netzwerke zwischen Partnern ermöglicht, die sich nicht vertrauen. Sawtooth wurde von Intel vorgeschlagen, sodass auch der erste Code aus den Toren von Intel in das Projekt kam. Immer noch hat Intel ein großes Interesse an dem Projekt.

Sawtooth ist zwar laut Behlendorf ein Enkel von Fabric, basiert allerdings auf einer ganz anderen Code-Basis. Es wurde größtenteils in Python geschrieben statt in Go. Das Alleinstellungsmerkmal von Sawtooth ist allerdings ein anderes Konzept für den Konsens-Mechanismus (Was sind Konsens-Mechanismen? ). Dieser ist nicht variabel wie bei Fabric. Wenn man sich für die Verwendung von Sawtooth entscheidet, entscheidet man sich für diesen besonderen Konsens-Algorithmus.

Der Konsens-Algorithmus heißt „Proof of elapsed Time“ und möchte eigentlich das verbessern, was wir als Proof of Work vor allem aus der Welt der Kryptowährungen kennen (auch „Mining“ genannt). Dabei implementiert PoET einen Hardware-basierten Zufallsgenerator, der auswählt, welcher Netzwerkknoten den nächsten Block der Blockchain schließen darf. Die Hardware-Voraussetzung, auf der dieser beruht, sind die Software Guard Extensions (Intel SGX) . Dabei handelt es sich um eine erweiterte x86-CPU-Architektur, die für Prozesse einen besonders geschützten Speicherbereich bereitstellt. Der mühselige Rätsel-Prozess beim PoW wird also durch eine schnelle Verlosung über die SGX beim PoET abgekürzt. Somit entsteht ein viel skalierbarer und energiesparender Konsens-Mechanismus. Leider hat sich dieser Mechanismus stark von der Hardware abhängig gemacht, die wiederum von Intel abhängig ist. Ideologisch ist der PoET fraglich, da der Konsens von einer zentralen Instanz kontrolliert werden könnte. Durch die benötigte SGX-Architektur werden homogene Blockchain-Netzwerke außerdem schwierig zu bewerkstelligen, da alle Knoten auf die richtigen physischen Maschinen angewiesen sind.

Der Einsatz von Sawtooth ergibt durchaus in einigen Kontexten Sinn. Trotzdem sollte man genau wissen, auf welchen technischen Gegebenheiten der Konsens basiert und wodurch er manipulierbar werden kann. Ein nicht vertrauenswürdiger Konsens stellt schließlich den gesamten Aufwand für eine Blockchain-Nutzung in Frage.

Burrow – Ein Verwandter der Ethereum Virtual Machine

Burrow befindet sich aktuell noch im Incubator-Status und in Version 0.17. Das Ziel von Burrow ist es, eine technologische Brücke zur Ethereum Blockchain zu bauen. Dies kommt daher, dass viele Organisationen hinter Projekt Hyperledger ebenfalls der Ethereum Enterprise Alliance beigetreten sind. Daher sind sie an beiden Ökosystemen interessiert und wollen auch selbst ein Nutzen daraus ziehen. Was Burrow also in seinem frühen Stadium bereits bietet, ist eine simple Blockchain-Architektur. Diese besteht aus drei Komponenten, die (wie bei Fabric und Sawtooth auch) redundant über das gespannte Private Blockchain Netzwerk verteilt werden müssen.

Eine Komponente von Burrow kümmert sich um die Herstellung von Konsens im Netzwerk und implementiert dabei Proof of Stake über die das Tendermint Protokoll . Zum Thema Proof of Stake hört man aus der Richtung des Ethereum Projektes viel über Casper . Casper und Tendermint unterscheiden sich in ihren Ansätzen, PoS umzusetzen, dazu gibt es einen sehr informativen Artikel auf Medium.com .

Bei der zweiten Komponente handelt es sich um die Implementierung der Ethereum Virtual Machine (EVM) . Mit dieser will Burrow eigentlich gar nicht weit von der Spezifikation der EVM abweichen. Vielmehr wird diese um Identitäten erweitert. Zu jeder Identität können spezifische Berechtigungen definiert werden. Somit macht Burrow aus der normalen Public Ethereum VM eine VM für eine Permissioned Blockchain.

Die dritte Komponente ist das API Gateway, das den State vom lokalen Ledger eines Knoten sowie den State der Distributed Ledger über REST und JSON-RPC nach außen anbietet.

Die Wahl von Burrow ist also besonders interessant, wenn bestehende Smart Contracts aus der Ethereum-Welt in einer Private bzw. Permissioned Blockchain genutzt werden sollen. Auch bei Burrow findet die Programmiersprache Solidity Anwendung in der Entwicklung der Smart Contracts. Die Gegebenheit von Proof of Stake als durchaus experimentellem Konsens-Mechanismus sollte ebenfalls in eine Entscheidung einbezogen werden.

Iroha – Die nebulöse Light-Variante

Iroha ist ebenfalls ein aktives Projekt, das aktuell an der Version 1.0 arbeitet. Die initiale Arbeit am Projekt kam von den japanischen Firmen Hitachi, Soramitsu, Colu und NTT Data. Die Prinzipien von Iroha ähneln Fabric ebenfalls sehr, jedoch auf Basis einer wiederum anderen Codebase. Iroha wird in C++ entwickelt, wobei vor allem auf eine moderne Codebase und ein sauberes Design gesetzt wird. Das Projekt sieht daher sein Alleinstellungsmerkmal in der hohen Performance und Einfachheit der Architektur. Es zielt auf Anwendungsfälle ab, in denen schnelle synchrone Transaktionen mit kleinem Payload benötigt werden. Hierfür werden Anwendungsfälle wie Mobile Applications genannt.

Business-Logik kann in Iroha ebenfalls in Chain-Code geschrieben werden. Hier steht Java als API zur Verfügung, das auf den Knoten jeweils als sandboxed JVM ausgeführt wird. Aspekte wie Währungen und die Kommunikation mit mobilen Endgeräten sind allerdings schon Features von Iroha, weswegen man nicht für jeden Anwendungsfall eigenen Chain-Code implementieren muss.

Seine wahre Nische hat Iroha aber laut Brian Behlendorf noch nicht gefunden. Darüber hinaus ist es schwer abzuschätzen, für welche Anwendungsfälle die Nutzung von Iroha besonders viel Sinn ergeben könnte. Jeder, der überlegt, es einzusetzen, sollte vorher ausgiebig damit experimentieren.

Indy – Verteiltes Identitätsmanagement

Auch Hyperledger Indy befindet sich noch im Incubator-Status und stellt eine weitere Implementierung eines Private-Blockchain-Knotens dar. Das Projekt macht es sich zur Aufgabe, eindeutige Identitäten global nutzbar zu verwalten. Die Identitäten werden dafür in einem eigenen Distributed Ledger verwaltet und sollen über Schnittstellen auch außerhalb des Private-Blockchain-Netzwerkes nutzbar gemacht werden. Das Identitäts-Tool „Sovrin“ der Sovrin Foundation nutzt Indy und trägt über diesen Weg einen signifikanten Anteil zur Entwicklung bei.

Das Herz von Indy hat wiederum einen weiteren Namen: Plenum. Es implementiert ähnliche Features wie in Fabric (Organisationen, Teilnehmer und damit verbundene Identitäten), jedoch speziell für den Anwendungsfall von Identitäts-Verwaltung, worin der Unterschied zum generellen Ansatz von Fabric liegt. Eine hilfreiche Übersicht über Plenum und die Integration mit Indy stellt dieses Dokument zur Verfügung. Plenum implementiert das Redundant Byzantine Fault Tolerance (RBFT) Protokoll.

Indy ist interessant für Permissioned-Blockchain-Konsortien, die untereinander auf vertrauenswürdige Art und Weise eindeutige Identitäten verwalten wollen. Diese können optional von weiteren Kreisen oder sogar öffentlich konsumiert werden. Das Projekt ist technisch von hoher Qualität und konzentriert sich voll und ganz auf die Bedürfnisse dieses einen Anwendungsfalles. Daher ist eine Nutzung für dezentralisiertes Identitätsmanagement empfehlenswert. Dafür muss nicht unbedingt ein eigenes Netzwerk aufgebaut werden. Die Tools von Indy lassen sich auch mit den anderen Plattform-Lösungen kombinieren.

Hyperledger Tools: Composer, Explorer und Cello

Die Tools aus dem Umbrella-Project zielen jeweils auf eine der vorgestellten Plattformen ab. Sie sind nicht untereinander bzw. über mehrere Lösungen hinweg nutzbar.

Composer: Hierbei handelt es sich um das am aktivsten entwickelte und mächtigste Tool. Man könnte es eher als Framework für Fabric bezeichnen. Die Nutzung von Composer bringt einfach nutzbare Konzepte für Fabric mit, man spricht von Business Network Definitions. Dies sind Sourcecode-Pakete, die ein Business-Netzwerk definieren. Darin befinden sich Berechtigungen, Abfragen, Teilnehmer-, Asset- und Transaktions-Definitionen sowie die Implementierung der unterschiedlichen Transaktionsarten. Eine paketierte BND kann auf alle Knoten eines Fabric-Netzwerkes deployed werden. Somit sehen wir ein Fabric-Netzwerk unter der Nutzung mit Composer nur noch als Plattform und Infrastruktur. Die meisten Low-Level-Konzepte von Fabric müssen wir ab jetzt nicht mehr benutzen. Die Nutzung von Composer ergibt definitiv immer Sinn, wenn Fabric schon genutzt wird.

Explorer: Der Name dieses Tools ist bereits sehr sprechend. Der Explorer kann ebenfalls in Verbindung mit Fabric genutzt werden. Er wird für einen Channel in einem Fabric-Netzwerk konfiguriert. Ab dann kann ein Web-Interface genutzt werden, um den State und die Geschichte im Distributed Ledger sichtbar zu machen. Das Tool eignet sich also für verschiedene Bedürfnisse unter der Nutzung von Fabric, z.B. wenn Parteien eine einfache Ansicht auf Daten in der Blockchain bekommen sollen.

Cello: Auch diesen Namen kann man schnell nachvollziehen. Cello ist ein Tool, um Blockchain-Netzwerke auf eine effiziente Art zu provisionieren und zu verwalten. Es kann dabei auch mit homogener Infrastruktur umgehen: Bare Metal, Virtual Clouds sowie Container-Orchestrierungscluster wie Kubernetes und Docker Swarm. Es kann mehrere Netzwerke verwalten, nicht nur eines. Außerdem wird der Status der Systeme über ein Dashboard dargestellt. Damit können Ressourcen auch skaliert und verwaltet werden. Bisher werden nur Fabric-1.0-Netzwerke unterstützt.

Fazit

Das Projekt Hyperledger verfolgt mehrere Ansätze zur Umsetzung von Private- und Permissioned-Blockchain-Anwendungen. Bei den größten und aktivsten Unterprojekten handelt es sich um die vorgestellten Plattformen. Fabric scheint davon als das reifste und aktivste angesehen zu werden.

Sie liefern Binaries sowie Docker-Images, um die teils verschiedenen Knoten-Rollen im Netzwerk zu platzieren. Diese Knoten können entsprechend konfiguriert werden, damit sie zusammenfinden und zusammenarbeiten können. Außerdem gibt es die Möglichkeit, Business-Logik zu entwickeln und sie auf den Knoten des Netzwerkes zu installieren. Damit beliebige Anwendungen (Web- sowie App-Frontends aber auch Backend-Systeme) mit dem entstehenden Blockchain-Netzwerk kommunizieren können, stellt jede Plattform Clients für unterschiedliche Programmiersprachen und Frameworks zur Verfügung.

Zusätzlich zu den Plattformen gibt es eine Schicht an Tools, deren Menge noch sehr übersichtlich ist. Diese Tools vereinfachen den Einsatz der Plattformen oder fügen ihnen neue Funktionalitäten hinzu. Wahrscheinlich wird die Zahl der Tools in der Zukunft noch stark ansteigen, da noch einige Fragen zum Thema Automatisierung, Migration und Deployment der einzelnen Plattformen gelöst werden müssen.

Für den Anfang war das allerdings ein Überblick über Hyperledger, der helfen soll, die einzelnen Projekte grob zu verstehen. Da die Plattformen unterschiedliche Ansätze für unterschiedliche Szenarien liefern, kann anhand des Überblicks eine Entscheidung für die richtige Plattform erleichtert werden.

Das umfangreichste, flexibelste und am generellsten ausgelegte Projekt davon ist aber Fabric. Das größte Tool aus dem Projekt, Composer, kann eher als Framework für Fabric gesehen werden und erleichtert die Entwicklung und Modellierung von Business-Netzwerken stark. Auch Cello und Explorer können mit Fabric genutzt werden. Dies zeigt, dass bei Fabric stark an gutem Tooling gearbeitet wird. Für die meisten Anwendungsfälle ist Fabric aktuell die beste Wahl.

In unserer Kolumne “blockcentric” bloggen wir, zusätzlich zu den bewährten Themen des codecentric-Blogs, über die Blockchain. Dabei möchten wir das Thema uneingeschränkt sowie breit gefächert betrachten: Technologie, Projekte, Organisation und Geschäft. Die Artikel können Ergebnisse unserer 20%-Zeit-Projekte sowie Neuigkeiten aus dem Themenbereich sein und zielen darauf ab, Ihnen die Blockchain näher zu bringen.

Auch auf unserer Blockchain Landing Page können Sie sich über unsere Aktivitäten und Angebote in dem Bereich informieren.

Wir freuen uns auf Ihr Feedback zur Kolumne und spannende Diskussionen über Ihre Use Cases.

Bisher veröffentlichte blockcentric-Posts