HYPERLEDGER FABRIC TIMELINE & ROADMAP

• Erste Preview eines privaten Blockchain-Frameworks.
• Nur zuvor freigegebene Identitäten dürfen mit der Blockchain interagieren.
• Unterstützung von frei programmierbarem Chaincode (smart contract).
• Eine Anbindung über die node.js API ist möglich.
• Die Knoten des Netzwerks werden in eigenen Docker Containern ausgeführt.

• Die erste offizielle Version von Hyperledger Fabric wurde freigegeben. Alle für die erste Version geplanten Features wurden umgesetzt.
• Auf der Seite von Hyperledger Fabric existiert eine umfangreiche Dokumentation zur Installation und Entwicklung von Hyperledger Fabric.
• Seit der letzten Preview wurden über 2000 Punkte korrigiert und verbessert.

• Unterstützung von node.js als Programmiersprache für Chaincode.
• Zur Benachrichtigung von Clients über abgeschlossene Transaktionen kann ab sofort der channelbasierte Event Service genutzt werden.
• Ab sofort können „Certfificate Revocation Lists“ (CRL) gepflegt werden, um ungültige Identitäten aus der Blockchain auszusperren. Außerdem kann innerhalb des Chaincodes auf die Identität des Transaktionserzeugers sowie auf Attribute aus Zertifikaten zugegriffen werden, um individuelle Berechtigungskonzepte zu ermöglichen.
• Änderungen an Benutzeridentitäten und Mitgliedschaften („affiliation“) können dynamisch geändert werden.
• Zur einfacheren Verbindung zum Netzwerk werden Profile in der node.js API unterstützt.
• Für die interne Kommunikation zwischen den verschiedenen Knoten wird nun Mutual TLS unterstützt.
• Daten innerhalb der Blockchain können ab sofort zusätzlich verschlüsselt werden. Innerhalb des Chaincodes steht dafür eine entsprechende Bibliothek bereit.
•  

• Neben der Abtrennung von Daten in verschiedene Channels kann ab sofort innerhalb eines Channels ein privater Datenbereich („Private Data Collection“) definiert werden. Daten innerhalb dieses Bereiches können nur von einem definierten Ausschnitt der Channel-Mitglieder verarbeitet werden.
• Zur einfacheren Administration des Blockchain Netzwerks können nun (neue) Netzwerk Services (Peers, Orderer, …) automatisch entdeckt werden.
• Eine Zugriffskontrolle ermöglicht nun die Konfiguration, welche Benutzeridentität mit welche Funktionen eines Peers arbeiten darf. Die Definition kann pro Channel separat erfolgen.
• Unterstützung von eigener Zustimmungs- (endorsement) und Validierungs- (validation) Logik.

• Unterstützung von Java als Programmiersprache für Chaincode. Damit steht nun die dritte Sprache zur Entwicklung von Chaincode bereit. Zuvor konnte der Code bereits in node.js und go erstellt werden.
• Durch den „Identity Mixer“ ist es möglich, Transaktionen anonym durchzuführen und nur tatsächlich benötigte Informationen preiszugeben. Persönliche Daten, die an den Benutzerzertifikaten hängen, werden verschwiegen.
• Bei Verwendung der CouchDB wird nun „Pagination“ unterstützt. Diese Technik ermöglicht es, von einer Ergebnisliste nur einen Ausschnitt zu lesen. Z.B. könnten zunächst die ersten 20 Treffer gelesen und dem Benutzer angezeigt werden, und erst durch eine Benutzeraufforderung die nächsten 20 Treffern dargestellt werden.
• Die Endorsement Policy kann nun nicht nur pro Chaincode definiert werden, sondern für besonders sensible Daten auch pro Schlüssel. Dies ermöglicht ein noch granulareres Berechtigungskonzept.
• Die veraltete „Event Hub“-Technik wird nicht mehr weiter unterstützt. Stattdessen sollte der channelbasierte Event Service genutzt werden, der bereits in Version 1.1 eingeführt wurde.

• Zur Fehlerdiagnose und zum Monitoring der Knoten existiert ab sofort ein Operations Service, der über eine REST-API angesprochen werden kann. Dies ermöglicht eine einfachere Bereitstellung und bessere Wartbarkeit.
• Das bestehende node.js SDK ist vereinfacht werden, so dass sich Entwickler stärker auf die Geschäftslogik fokussieren können.
• Als erste Version von Hyperledger Fabric wird 1.4 einen Langzeit-Support (LTS) erhalten. Dieser ist zunächst bis Januar 2020 begrenzt. Fehlerkorrekturen werden als Patch Releases (1.4.1, 1.4.2, ...) veröffentlicht werden.

• Die Alpha-Version bietet einen Vorausblick und ist nicht für Produktionszwecke geeignet.
• Ab Version 2.0 wird der Transaktionstyp „Fabtoken“ unterstützt. Dadurch wird es ermöglicht, die Besitzansprüche außerhalb der Blockchain bestehender Werte durch Hyperledger Fabric zu verwalten. Der reale Wert wird dazu als virtueller Token in der Blockchain mit seinem Anfangsbesitzer hinterlegt. Der Besitzer kann nun jederzeit den Token und damit den realen Besitzanspruch mit einem anderen Teilnehmer tauschen, wobei dies jederzeit über die Blockchain abgesichert ist. Außerdem kann der aktuelle Besitzer eines Tokens diesen einlösen und erhält im Gegenzug den realen Wert zurück.
• Die Verwaltung von Chaincodes kann nun dezentral erfolgen. Über die Parameter und mögliche Updates des Chaincodes entscheidet die Mehrheit der Teilnehmer des jeweiligen Channels. Die Endorsement Policy kann zudem auch nachträglich geändert werden. Ein erneutes Installieren des Chaincodes entfällt.
• Die Docker Images von Hyperledger Fabric nutzen ab sofort Alpine Linux. Diese Linux Distribution zeichnet sich vor allem durch seine Sicherheit und Schlankheit aus. Die Container benötigen weniger Speicherplatz und lassen sich schneller starten.
• Bereits seit Version 1.4.1 besteht die Möglichkeit, den Konsens-Mechanismus “Raft” zu verwenden. Dadurch kann im produktiven Betrieb auf den Einsatz eines Kafka Clusters verzichtet werden.

• Der Konsens-Mechanismus „Raft“ kann verwendet werden. Der Einsatz eines Kafka Clusters kann somit vermieden werden.
• Es wurden neue Gesundheitschecks eingeführt (u.a. für CouchDB, Kafka, Orderer und Endorser).
• Das „CAR“ Format wird nicht mehr unterstützt.
• Unterstützung von Go 1.11.5

• Die Migration eines Kafka-basierten Orderers nach Raft wurde umgesetzt.
• Ein Rollback für einen Channel kann über die CLI durchgeführt werden. Der Zustand kann wahlweise auf einen beliebigen vorherigen Block oder den Genesis Block zurückgesetzt werden.
• Die Orderer-Endpunkte können nun pro Organisation definiert werden.
• Bei Abfragen von historischen Daten wurden Informationen aus Blöcken 256, 512, 768 usw. nicht zurückgegeben. Dies wurde korrigiert.

• Zertifikate für die Rollen von Orderer und Administator-Identitäten von Organisationen können nun ausgestellt werden.
• Wenn private Datenbereiche aktiviert werden, müssen Peers nun nicht mehr neu gestartet werden. 

• Wenn der Orderer umgezogen wurde, konnten anschließend Peers nicht mehr einem Channel hinzugefügt werden, da die Orderer-Adresse aus dem Genesisblock ermittelt wurde. Ab sofort kann die (neue) Orderer-Adresse bei der Konfiguration der Peers hinterlegt werden.Es werden nun Warnungen protokolliert, bevor Zertifikate ablaufen.
• Es werden nun Warnungen protokolliert, bevor Zertifikate ablaufen.
• Unterstützung von Go 1.12.12

• Die Beta-Version bietet einen Vorausblick und ist nicht für Produktionszwecke geeignet.
• Die Beta-Version ist „feature complete“.
• Ein Upgrade-Guide ist auf der offiziellen Homepage verfügbar. Manuelle Änderungen müssen sowohl für die Datenbanken der Peers als auch im Chaincode (nur bei golang) vorgenommen werden.
• Das Ausführen von Chaincode wird nicht mehr zwangsweise in einem Docker Container stattfinden müssen. Docker wird der Standard bleiben. Kompiliert und ausgeführt werden kann der Chaincode aber auch durch externe Services, bspw. durch Kubernetes Pods.
• Die Performance beim Verwenden der CouchDB wurde verbessert.
• Die Konsensus „Solo“ und „Kafka“ sind überholt und werden zukünftig wegfallen.
• Das in der Version 2.0 Alpha eingeführte Fabtoken Management wurde wieder entfernt. In einer späteren Version wird es in überarbeiteter Form wieder eingeführt werden.

• Chaincodes können ab sofort dezentral verwaltet werden. Mehrere Organisationen können nach erfolgter Übereinstimmung Parameter des Chaincodes ändern (u.a. die Endorsement Policy).
• Die privaten Datenbereiche wurden erweitert, so dass die Daten nicht mehr für einzelne Teilnehmer eines Channels freigegeben werden müssen. Stattdessen können die Informationen mit Organisationen geteilt werden.
• Chaincode kann ab sofort über externe Tools kompiliert und ausgeführt werden. Dies ist eine optionale Möglichkeit.
• Durch neue Caching Möglichkeiten der Peers kann die Performance der CouchDB erhöht werden.

• Es kann eine separate TLS Konfigurationen für Raft Cluster und Clients angegeben werden.
• Die Anzahl von gleichzeitigen TCP-Verbindungen zwischen Peers und der CouchDB wurde reduziert.

• Die Version beinhaltet nur Fehlerkorrekturen.

Diese Version enthält diverse Fehlerbehebungen, unter anderem die folgenden:

• In bestimmten Situationen konnte es zu abweichenden Ergebnissen der Endorsement Policy kommen.
• Kafka Cluster können nachträglich um weitere Knoten ergänzt werden. Bisher führte dies zu einem Absturz.
• Bisher haben auch Peers von Organisationen, die nicht Bestandteil eines privaten Datenbereichs waren, diesen erhalten. Dieses Problem wurde behoben.
• Konfigurierte Validierungen für Blöcke wurden bisher ignoriert. Nun werden sie beim Erstellen eines Channels berücksichtigt und müssen konfiguriert werden.

• Peers können ab sofort mit einem Limit versehen werden, welches die maximale Anzahl an parallelen Anfragen limitiert. Anfragen darüber hinaus werden mit einem Fehler abgelehnt.
• Private Schlüssel im SEC 1 Format werden neuerdings unterstützt.
• In Docker Images wird Alpine 3.11 eingesetzt.
• Ein Update auf die Go-Version 1.14.1 ist erfolgt.

• Die Version beinhaltet nur Fehlerkorrekturen.
• Unterstützung von Go 1.13.9

• Ein Problem bei der Untestützung mehrerer Signaturen von einer Organisation wurde gelöst.
• Die Meldungen von möglichen Fehlern bei der Installation von Chaincode sind nun besser verständlich.
• Ein Problem im Zusammenhang mit fehlerhaften Chaincode Builds und dem erneuten Installieren von Chaincode wurde behoben.

• TLS 1.3 wird ab sofort unterstützt und automatisch verwendet.
• Die Details eines Chaincodes können ab sofort abgefragt werden.
• Der Orderer kann nun ohne Genesisblock erneut gestartet werden, sofern der Genesisblock auf „Datei“ eingestellt ist.
• In bestimmten Konstellationen konnte es zu Problemen kommen, wenn ein Orderer einen Channel zuerst verlassen hat und später wieder eingetreten ist. Der Fehler wurde korrigiert.
• Die Performance bei der Verwendung von privaten Datenbereichen wurde verbessert.
• In Docker Images wird Alpine 3.12 eingesetzt.
• Ein Update auf die Go-Version 1.14.4 ist erfolgt.
• Ein Update auf die CouchDB Version 3.1.0 ist erfolgt.
• Die Beispiele und Tutorials zum Erstellen eines ersten Netzwerks wurden entfernt.
• Die Konsenstypen „Solo“ und „Kafka“ wurden als “deprecated“ markiert.
• Der alte Chaincode Lebenszyklus der Versionen 1.x ist als „deprecated“ markiert. Im Update-Guide auf Version 2.x ist beschrieben, wie eine Anpassung erfolgen kann.

• Die Version beinhaltet nur Fehlerkorrekturen.
• Unterstützung von Go 1.13.12

• Es wurden Verbesserungen und Korrekturen im Umgang mit auslaufenden oder ausgelaufenen Zertifikaten durchgeführt.
• Die Effizienz beim Einsatz von Hardware Security Modulen (HSM) wurde verbessert.

• Die maximale Größe von gRPC Nachrichten kann nun konfiguriert werden. Der Standard ist 100MB.
• Unterstützung von Go 1.16.7
• Unterstützung von CouchDB v3.1.1

• Es wurden Verbesserungen und Korrekturen im Umgang mit auslaufenden oder ausgelaufenen Zertifikaten durchgeführt.
• Die Effizienz beim Einsatz von Hardware Security Modulen (HSM) wurde verbessert

• Die API zum Beitreten und Verlassen von Channels wurde erleichtert. Dadurch kann der System Channel wegfallen, was wiederum die Performance und Skalierbarkeit verbessert. Da der Orderer außerdem nicht mehr in dem Prozess involviert ist, wird der Datenschutz somit erhöht.
• Der aktuelle Status eines Channels kann als „Snapshot“ festgehalten werden. Dadurch können Peers einem Channel basierend auf diesem Snapshot beitreten. In der Folge müssen vor dem Checkpoint liegende Daten nicht geladen werden, wodurch Zeit und Speicherkapazität reduziert werden können.
• Bei der Konfiguration eines Orderers muss nun ein Arbeitspfad angegeben werden.
• Alle Korrekturen bis zu Version 2.2.1 sind in die Version 2.3.0 eingeflossen.
• Unterstützung von Go 1.14.12

• Die Version beinhaltet nur Fehlerkorrekturen.

• Es wurden Korrekturen beim Löschen von Schlüsseln durchgeführt. Je nach verwendetem Chaincode konnte das Verhalten voneinander abweichen.
• Falls Schlüssel in privaten Datenbereichen gelöscht wurden, sollte eine Reparatur der defekten Blöcke durchgeführt werden.
• Unter Umstanden wurden PKCS#11 Sitzungen nicht korrekt geschlossen. Der Fehler wurde korrigiert.
• Beim Raft-Konsensus kann nun der Tick Intervall in der Orderer-Konfiguration definiert werden.
• Unterstützung von Go 1.14.12

• Die Version beinhaltet nur Fehlerkorrekturen.

• Es wurden Korrekturen beim Löschen von Schlüsseln durchgeführt. Je nach verwendetem Chaincode konnte das Verhalten voneinander abweichen.
• Falls Schlüssel in privaten Datenbereichen gelöscht wurden, sollte eine Reparatur der defekten Blöcke durchgeführt werden.

• Beim Einsatz von GO 1.15.x kann es zu Abweichungen bei der Überprüfung von Namen im Vergleich zu vorherigen GO-Versionen kommen. Daher wurde ein Modus eingeführt, so dass die Prüfung die gleichen Ergebnisse wie zuvor liefert.
• Unterstützung von Go 1.15.7

• Ein Fehler beim Zurücksetzen auf einen Snapshot mit Block Nummer 0 wurde korrigiert.
• Unterstützung von Go 1.15.7
• Unterstützung von CouchDB v3.1.1

• Unterstützung von Go 1.14.12
• Unterstützung von CouchDB v2.3.1
• Unterstützung von Fabric baseimage 0.4.22
• Ein Fehler bei der goleveldb wurde behoben. Dieser konnte zu korrupten Manifest-Dateien führen.
• Das „fabric-couchdb“ Docker Image wird nicht mehr gewartet. Stattdessen sollte das offizielle Docker Image von Apache verwendet werden.

• Die maximale Größe von gRPC Nachrichten kann nun konfiguriert werden. Der Standard ist 100MB.
• Unterstützung von Go 1.16.7
• Unterstützung von CouchDB v3.1.

• Mit dem neuen Befehl „unjoin“ kann ein Peer einen zuvor betretenen Channel wieder verlassen.
• Das Fabric Gateway ist ein neuer Service, der auf einem Peer betrieben werden kann. Der Service kann Transaktionen verarbeiten und bietet dabei folgende Vorteile:
  • Eine Applikation kann Transaktionen direkt an einen vertrauenswürdigen Peer senden.
  • Fabric Gateway kann die richtige Endorsement Policy selbst auswählen.
• Ein neues SDK (v1.0.0) für die Programmiersprachen Node, Java und Go wurde freigegeben. Neben den Sprachfeatures des vorherigen SDKs kann das neue Fabric Gateway direkt angesprochen werden.
• Die Package-Id zu einem Chaincode kann berechnet werden, ohne dass der Chaincode zuvor installiert werden muss.
• Der System Channel ist ab sofort als veraltet anzusehen und wird zukünftig nicht mehr unterstützt.
• orrekturen und Verbesserungen aus vorherigen Versionen wurden übernommen (bis einschließlich Version 2.3.3)
• Unterstützung von Go 1.16.7
• Unterstützung von CouchDB v3.1.1

• Seit Version 2.0 kann Chaincode direkt als Service betrieben werden, was insbesondere in Kubernetes-Umgebungen Vorteile hat. Bisher musste dazu ein eigenes Skript erstellt werden, das den Chaincode ausführen kann. Ab dieser Version wird solch ein Tool mitgeliefert.
• Das Load Balancing wurde verbessert.
• Beim neuen Fabric Gateway kann die Anzahl gleichzeitiger Zugriffe konfiguriert werden. Die Garbage Collection beim Fabric Gateway wurde verbessert.
• Beim neuen Fabric Gateway kann die Anzahl gleichzeitiger Zugriffe konfiguriert werden. Die Garbage Collection beim Fabric Gateway wurde verbessert.
• Antworten im Fehlerfall beinhalten nun weniger Informationen. Dadurch wird die Größe der Antwort reduziert, was Verbindungsabbrüche reduziert.

• Ein Fehler beim Erstellen von Channeln wurde behoben. Dieser konnte dazu führen, dass der Orderer Service abgestürzt ist.
• Unterstützung von GO 1.17.5
• Unterstützung von CouchDB v3.1.1

• Ein Fehler beim Auslesen der Endorsement Policy Optionen wurde behoben.
• Bisher hat ein Peer die Verbindung zum Orderer nicht geschlossen, wenn dieser aus dem Channel entfernt wurde. Dies wurde korrigiert.
• Unterstützung von Go 1.17.5

• Mehrere Fehler im Zusammenhang mit TLS Zertifkaten wurden behoben.

• Abgelaufene TLS Zertifikate konnten dazu führen, dass Peer und Orderer nicht mehr starten konnten. Der Fehler wurde behoben.
• Unterstützung von GO 1.18.2
• Unterstützung von CouchDB v3.2.2
• Unterstützung von Alpine 3.16

• Das Logging von Endorsement Policies wurde verbessert, um die Fehlersuche zu vereinfachen.
• Das Fabric Gateway kann nun auch System Chaincodes ausführen.
• Unterstützung von Go 1.18.2
• Unterstützung von CouchDB v3.2.2
• Unterstützung von Alpine 3.16

• Fehlerhafte Consensus Anfragen konnten den Orderer zum Absturz bringen. Dies wurde korrigiert.

• Fehlerhafte Consensus Anfragen konnten den Orderer zum Absturz bringen. Dies wurde korrigiert.

• Weitere Einstellungen der core.yaml-Datei können nun über Umgebungsvariablen überschrieben werden.

• Fehlerhafte Anfragen eines Fabric Gateways an einen Peer konnten diesen zum Absturz bringen. Der Fehler wurde behoben.
• as mit Version 2.4.1 eingeführte Tool zum Betreiben von Chaincode als Service wurde in alle Release Verteilungen aufgenommen.

• Die Log-Meldungen für den Peer wurden erweitert.
• Unterstützung von GO 1.18.7

• Beim Fabric Gateway konnte es zu Null Pointer Exceptions kommen. Dies wurde korrigiert.
• Zur Verwendung von Hardware Security Modulen (HSM) können nun Umgebungsvariablen verwendet werden.

• Wenn ein Fabric Gateway den Fehlercode 500 von einem Orderer bei einer Transaktion zurückbekommt, wird es die Transaktion wiederholen.
• Zur Konfiguration des Timeouts bei Anfragen eines Fabric Gateways an den Orderer gibt es nun einen Parameter.
• Einem Peer können nun per Konfiguration bestimmte Zieladressen übergeben werden, die den Standard überschreiben. Damit können notwendige Aktualisierungen, die der Peer noch nicht erhalten hat, vorgenommen werden.
• Unterstützung von Go 1.18.10
• Unterstützung von CouchDB v3.2.2

• Das Fabric Gateway verwendet nun den Ledger des Peers zur Bestimmung des Endorsers. Dadurch wird sichergestellt, dass immer die aktuellsten Informationen genutzt werden.
• Das Fabric Gateway verwendet nun asynchrone Verbindungen. Zuvor konnte bei Verbindungsproblemen das Limit an gleichzeitigen Verbindungen schnell erreicht werden.