Hyperledger Fabric :conwic
Membership Service Provider
Bei Hyperledger Fabric handelt es sich um eine private und "permissioned" Blockchain. Teilnehmen kann nur, wer im Vorfeld berechtigt wurde. Diese Berechtigung erfolgt in Form von X.509-Zertifikaten. Dies gilt sowohl für Peers als auch für Benutzer, die Transaktionen vornehmen möchten.
 
Die Ausstellung der Zertifikate kann durch Hyperledger Fabric Tools wie den CA-Server erfolgen. Dabei kann gezielt gesteuert werden, ob einzelne Benutzer wiederum neue Zertifikate erstellen und somit Kollegen einen Zugriff auf die Blockchain gewähren dürfen. Auch ist es möglich, beliebige Attribute an Zertifikate zu hängen. Diese können im Chaincode ausgewertet werden. Dadurch könnten unterschiedliche Zugriffe auf die Blockchain (nur lesen, lesen und ändern) auf Rollenebene abgebildet werden.
 
Außerdem ist es möglich, Hyperledger Fabric an eine bestehende CA-Infrastruktur anzuhängen. Auch eine Anbindung an das LDAP ist vorgesehen.
Peers
Bei Hyperledger Fabric können Peers unterschiedliche Rollen einnehmen. Möchte ein Benutzer Daten ändern oder ergänzen, wird über die Client API ein Antrag erstellt. Dieser Antrag muss an definierte Peers gesendet werden. Welche das sind, wird in der sogenannten „Endorsement policy“ festgelegt.
 
AND('Org1.member', 'Org2.member', 'Org3.member')
Endorsement policy mit Zustimmung von 3 Organisationen
 
Diese Endorser genannte Peers führen die Anträge aus, in dem der zuständige Smart Contract aufgerufen wird. Bei Erfolg signiert der Endorser den Antrag und sendet ihn zurück den Client.
 
Sobald alle Anträge signiert beim Client vorliegen, schickt er diese als eine Transaktion an den Orderer. Der Orderer ist ein bestimmter Client mit der Aufgabe, die Reihenfolge von Transaktionen sicherzustellen und sie in Blöcke zu verpacken. Abgeschlossene Blöcke verschickt er an alle Peers (inkl. Endorser).
 
Im einfachsten Fall existiert genau ein Orderer. Das Konsens-Protokoll ist somit simpel, da der Orderer sich nicht mit jemand anderem abstimmen muss. Dieser Fall ist vor allem für die Entwicklung vorgesehen. Für den produktiven Betrieb kann auf ein Kafka Cluster zurückgegriffen werden. Außerdem arbeitet das Hyperledger Fabric Team an einer Unterstützung für Simplified Byzantine Fault Tolerance.
 
Sobald ein Peer einen Block vom Orderer erhält, prüft er die Transaktionen nochmals gegen die Endorsement policy. Danach wird die Peer-lokale Blockchain erweitert und es findet eine Benachrichtigung der Clients statt.

 

Channels
Zwei separierte Channel mit einem Benutzer, der auf beide Channels Zugriff hat
 
Das Channel-Konzept ermöglicht die Aufteilung von Daten in getrennte Bereiche (Channels). Jeder Channel hat seine eigenen Peers (wobei ein Peer zu mehreren Channels gehören kann), Member, Endorsement policy sowie Chaincode. Ein Channel kann somit als privater Kommunikationsweg innerhalb des Hyperledger Fabric Netzwerks angesehen werden. Auch physikalisch findet eine Trennung statt, d.h. jeder Peer hat für jeden (beigetretenen) Channel eine separate Ledger-Datei.
 
Smart Contracts
Smart Contracts werden als selbst programmierbarer Teil erstellt und im Hyperledger Fabric Umfeld als Chaincode bezeichnet. Änderungen am Ledger sind nur über Chaincodes möglich. In der Client API muss folglich bei Anträgen an den Peer übergeben werden, welcher Chaincode mit welchen Daten aufgerufen werden soll.
 
Der Chaincode kann in verschiedenen Programmiersprachen geschrieben werden, u.a. go und Javascript. Nach der Codierung wird er innerhalb eines Channels installiert und kann anschließend aufgerufen werden. In einem Channel können dabei mehrere Chaincodes installiert werden. Auch ein Upgrade eines Chaincodes auf eine neuere Version ist möglich.

func (s *SmartContract) Invoke(APIstub shim.ChaincodeStubInterface) sc.Response {

function, args := APIstub.GetFunctionAndParameters()

// ledger functions
if function == "initLedger" {
     return s.initLedger(APIstub)
}

// Retrieve role
if len(args) <= 0 {
     return shim.Error("No role provided")
}

...

Ausschnitt eines Chaincodes, in go programmiert

 

DApps
Auf Basis eines Hyperledger Fabric Netzwerks können Applikationen entwickelt werden, die von der dezentralen Architektur profitieren. Zur Abgrenzung von „normalen“, zentralen Applikationen (Apps) wird von DApps gesprochen.
 
DApps helfen bei der Verwaltung von eigenen, in der Blockchain vorhandenen, Werten. Diese Werte könnten Kryptowährungen, aber auch, je nach Anwendungsfall der Blockchain, beliebige materielle oder immaterielle Vermögensgegenstände sein. Im Kontext von Blockchain wird häufig von Assets gesprochen.
 
Ein Asset wird innerhalb des Chaincodes definiert und als Schlüssel-Wert-Paar gespeichert. Auf die einzelnen Werte eines Assets kann zur Prüfung auf Validität im Chaincode zugegriffen werden. Auch eine Anpassung kann dabei erfolgen, wie z.B. eine Berechnung eines Wertes oder eine Statusänderung. Ebenso kann während der Verarbeitung eines Assets ein weiterer Asset geladen und angepasst werden. Verknüpfungen zwischen Assets können analog zum relationalen Datenbankmodell als Fremdschlüssel definiert werden.
 
type Car struct {
Make   string  `json:"make"`
Model  string  `json:"model"`
Color  string  `json:"color"`
Year   int     `json:"year"`
Owner  string  `json:"owner"`
}
Definition eines Autos als Asset
Vorteile von Hyperledger Fabric
Ergänzend zu den Vorteilen der Blockchain-Technologie bietet Hyperledger Fabric weitere Möglichkeiten:
  • Separation von Daten und Teilnehmern
  • Definierter Teilnehmerkreis
  • Flexible & frei programmierbare Smart Contracts
  • Performance
Durch das flexible Channel-Konzept kann eine Separierung der Daten und Teilnehmer innerhalb der Blockchain erfolgen.
 
Durch die Erstellung und Verteilung der Zertifikate kann gezielt einzelnen Personen oder Organisationen ein Zugriff auf die Blockchain gewährt werden. Weiterhin kann durch Attribute innerhalb des Zertifikats eine noch granularere Berechtigung für einzelnen Funktionen des Smart Contracts erfolgen. Ebenso ist das Widerrufen von ausgestellten Zertifikaten möglich.
 
Im Gegensatz zu den auf Währungen spezialisierten Blockchain-Frameworks kann die Vertragsgestaltung Daten jeder Art annehmen und verarbeiten. Ähnlich einer Datenbank kann die Datenstruktur frei angepasst werden; der zugehörige Algorithmus wird selbst entwickelt.
 
Die Peers speichern ihre Daten in einer Datenbank. Nativ unterstützt werden LevelDB und CouchDB. Bei letzterer ist die entsprechende Abfrage-Sprache innerhalb des Chaincodes verfügbar. Dadurch kann gezielt und performant nach bestimmten Daten gesucht werden. Auch die Wahl des Konsens-Mechanismus unterstützt die Performance, da aufwändige Rechen- und Kommunikationsleistung eingespart wird.