Software Engineering

Oracle Blockchain Cloud Service – ein Erfahrungsbericht

Letztes Jahr stellte Oracle den Autonomous Blockchain Cloud Service (OABCS) auf Basis des Blockchain Frameworks Hyperledger Fabric für die Allgemeinheit zur Verfügung. Dabei handelt es sich um einen Blockchain-as-a-Service für sogenannte Smart Contracts – Intelligente Verträge. Diese werden entweder in Golang, JavaScript oder Java verfasst und können über Schnittstellen (sogenannte Oracles) auf externe Datenquellen zugreifen.

Hyperledger Fabric, eine open-source Plattform für dezentrale Smart Contracts (bei Hyperledger Fabric Chaincode genannt) ist eine sogenannte Permissioned Blockchain. Eine Teilnahme in einem Hyperledger Fabric Netzwerk ist im Gegensatz zu Public Blockchains wie z. B. Bitcoin nur auf Einladung möglich. Dadurch ist auch der Prozess des Mining, wie bei diversen Cryptowährungen erforderlich, hinfällig. Bei Hyperledger Fabric wird ein sogenanntes Konsens System verwendet, bei dem eine Mehrheit der am Netzwerk beteiligten Parteien einer Änderung der Blockchain, dem sogenannten Proposal (Vorschlag) zustimmen muss, damit diese tatsächlich abgespeichert wird. [1]

Was kann der OABCS?

Der Cloud Service wurde ins Leben gerufen, um die Einrichtung eines Hyperledger Fabric Netzwerks deutlich zu vereinfachen und den Fokus der Entwicklung mehr auf den Use Case des jeweiligen Projekts legen zu können. Es ist möglich, einfach und schnell ein Netzwerk aufzusetzen oder Teil eines bereits bestehenden Netzwerks zu werden. Auch können zu Testzwecken Beispielchaincodes deployed werden. Es ist anschließend möglich einen neuen Chaincode im Netzwerk zu verteilen und Abfragen an diesen zu stellen. Dies geschieht mittels der REST-Schnittstelle, welche der Cloud-Service zur Verfügung stellt. Standardmäßig kann jeder Peer nur mithilfe des GRPC Protokolls kommunizieren. Um die vorhandene Infrastruktur zu visualisieren, stellt der Service ein Dashboard bereit, über das auch die Konfiguration erfolgt.

Wofür kann der OABCS genutzt werden?

Für Smart Contracts gibt es viele potentielle Anwendungsszenarien, viele manuelle Prozesse lassen sich durch die Blockchain Technologie automatisieren. Als Proof-of-Concept haben wir einen dezentralen Rohstoffmonitor entworfen, welcher das Aushandeln von Produkteinkaufspreisen im Einzelhandel automatisieren soll. Der Einkaufspreis orientiert sich dabei anteilig an den börsenaktuellen Rohstoffpreisen, was den Prozess des Handelns für beide Parteien fair gestaltet. Der aktuelle Rohstoffpreis wird dabei über eine sogenanntes Oracle, eine externe Schnittstelle außerhalb des Smart Contracts, zur Verfügung gestellt. Realisiert werden kann das in Go über das Abfragen einer REST-API, welche vorab im Chaincode definiert wird. Anschließend ist für den Nutzer möglich, den finalen Preis eines Produkts über eine Oberfläche, welche auf die REST-API des OABCS zugreift abzufragen und dieses auch zu bestellen. Eine Bestellung wird dann von allen beteiligten Parteien validiert und auf der Blockchain gespeichert. Eine zeit- und damit auch kostenintensive Preisverhandlung wird damit vermieden. Auch ist es möglich, Bestellungen für ein Datum in der Zukunft anzulegen, um auf sinkende Rohstoffpreise zu spekulieren oder bei Unterschreitung eines gewissen Preises automatisch eine Bestellung auszuführen (wie bei einer Limit-Order im Aktienhandel). Um Trends zu erkennen und Produkte zu vergleichen können verschiedene Preisentwicklungen in Diagrammen verglichen und deren Zusammensetzungen angezeigt werden.

Beispielstack für den OABCS

Entwickeln von Chaincode mit Go

Wie bereits beschrieben, kann Chaincode mit Hilfe von Go, JavaScript und Java erstellt werden, wobei Go die in der Vergangenheit am stärksten unterstütze Sprache darstellt.  Auf der Hyperledger Fabric Website findet sich in der Dokumentation sowohl Go als auch JavaScript Beispiel Chaincode, Java ist nur teilweise vertreten. Bei esentri haben wir uns für die Entwicklung mit Go entschieden, um die Vorteile einer stark typisierten Sprache zu nutzen.

Am Anfang jedes Smart Contracts muss das Hyperledger Fabric „shim“ und das „peer“ package importiert werden, um Smart Contract Funktionen bereitstellen zu können und Antworten an die Peers im Netzwerk zu senden. Jeder Aufruf eines Chaincodes landet anschließend in der Invoke Funktion des Chaincodes. Von dort aus werden die Argumente, welche dem Invoke Aufruf mitgegeben wurden nach dem Funktionsnamen gefiltert und die passende Funktion aufgerufen (z. B. „createOrder“). Diese wiederum verarbeitet die restlichen mitgegebenen Argumente, wie den Inhalt und die Stückzahl einer Bestellung, welche mit dem Funktionsaufruf erstellt werden soll. Nachdem Preise kalkuliert und eine Bestellung auf der Blockchain angelegt wurde, gibt die Funktion über das zuvor importierte Shim mit shim.success() den Erfolg der Funktion zurück. Dabei kann auch ein Payload mitgegeben werden, z. B. der eindeutige Key der Bestellung. Falls das Anlegen einer neuen Bestellung nicht erfolgreich war, weil z.B. die API der Rohstoffbörse ausfällt und eine Preiskalkulation so nicht möglich ist, wird eine Fehlermeldung mit shim.Error() zurückgegeben.

Um die mit der Zeit wachsende Komplexität eines Chaincodes zu beherrschen und Fehler vor einem finalen Deployment zu vermeiden – Stichwort „Code is Law“ – sollte ein Smart Contract vorher auch getestet werden. Dazu kann das „testing“ Package, welches bereits in Go integriert ist, verwendet werden. Um alle Funktionalitäten des Chaincodes darzustellen, müssen diese vorher gemockt werden. Dazu kann wieder das Package „shim“ importiert werden, welches Funktionen wie getState und Invoke zur Verfügung stellt um Schreib- und Lesevorgänge auf der Blockchain zu ermöglichen.

Alle Tests können anschließend mit dem Befehl „go test“ ausgeführt werden. Auch eine Analyse der Testabdeckung ist möglich. Dafür kann der Befehl „go test – -coverprofile=coverage.out“ und anschließend „go tool cover -html=coverage.out“ ausgeführt werden. Anschließend wird detailliert für jede Zeile die Testabdeckung angezeigt. Weitere Analysen der Codequalität sind z.B. mit SonarQube möglich, formatiert wird der Code je nach verwendetem Editor automatisch mit Go tools wie „gofmt“ oder „goreturn“

Bevor der Chaincode auf den OABCS geladen wird, ist es sinnvoll diesen auch lokal zu testen, um etwaige Fehler frühzeitig zu erkennen. Dies kann durch lokales, manuelles testen erfolgen. Um den Chaincode lokal zu installieren kann die Build-your-first-network Anleitung auf der Hyperledger Fabric Seite verwendet werden. Auf diesem lokal erzeugten Netzwerk wird die gerade entwickelte Chaincode Version installiert. Abfragen sind anschließend über den Hyperledger Fabric CLI Docker Container möglich. Alternativ kann dafür auch ein simples JavaScript Tool geschrieben werden, wie es im Hyperledger Fabric Samples Repository im Fabcar Beispiel verwendet wird. [2] In diesem Tool wird über das Hyperledger Fabric SDK for Node.js eine Chaincode Aktion ausgeführt.

Gerade bei großen Projekten ist es jedoch oft unübersichtlich, welche verschiedenen Funktionen der Chaincode anbietet, genauer gesagt, welche Parameter diese Funktionen akzeptieren und benötigen. Da die Parameter als Kette von Argumenten an den Chaincode übergeben werden, ist es sinnvoll, dies direkt in der Funktion in Form eines Kommentars zu erläutern. Es erleichtert sowohl das lokale Testen als auch die Dokumentation, welche für die REST-Schnittstelle des OABCS notwendig ist.

Vor- und Nachteile des Blockchain Cloud Service

Im Gegensatz zu einem standalone Hyperledger Fabric Netzwerk ist der OABCS deutlich leichter in bestehende Infrastruktur zu integrieren. Wie oben beschrieben ist es über die REST-Schnittstelle direkt möglich, eine Query oder Invoke auf der Blockchain auszuführen. Bei kleineren Anwendungen kann ein Frontend direkt, ohne eine zusätzliche Middleware auf den Service zugreifen. Über das Dashboard lässt sich jederzeit der Zustand der einzelnen Peers kontrollieren, Logs auslesen und verwendete Chaincode Versionen anzeigen, was sonst nur müßig über Konsolenabfragen möglich ist.

Chaincode Upgrade Wizard

Der OABCS bietet darüber hinaus einen einfachen Update Wizard, welcher eventuelle Änderungen an einem Smart Contract erleichtert. Dies ist z. B. der Fall, wenn ein Bug vorhanden ist oder ein neues Feature hinzugefügt werden soll. In dem Service werden die Vorteile von Hyperledger Fabric mit den Vorteilen der Oracle Cloud gepaart, wie schnelle Verfügbarkeit, Performance und Sicherheit. Das ist vor allem durch die Anbindung an den Oracle Identity Cloud Service möglich, welche die komplexe Zertifikatsinfrastruktur um Hyperledger Fabric erleichtert. Dabei kann für die Abfrage des an die REST Schnittstelle Oauth2 verwendet werden. Des Weiteren ist es möglich, Peers eines anderen Netzwerks über Zertifikate hinzuzufügen. So können auch Teilnehmer, welche nicht die Oracle Cloud verwenden dem Netzwerk hinzugefügt werden.

Während des Entwicklungsprozesses erwies sich die Dokumentation des Cloud Service teilweise als lückenhaft. So fehlten z. B. eine detaillierte Oauth2 REST Schnittstellen Beispielabfrage des Cloudservice und eine Anleitung, in der die erforderlichen Urls und Secrets zu finden sind. Lediglich Beispiel Invoke und Query Abfragen sind über den Oracle Blockchain Platform API Catalog verfügbar. Auch wird bei einer fehlerhaften Abfrage oft ein 400 Bad Request zurückgegeben, eine genaue Fehlermeldung bleibt dem Nutzer jedoch vorenthalten. Manuelle Fehlermeldungen aus dem Chaincode werden vom Service jedoch zurückgegeben, ebenso wie Peer Fehlermeldungen (z. B. im Falle eines nicht akzeptierten Proposals).

Im Hintergrund verwendet Hyperledger Fabric eine sogenannte State Datenbank, welche wahlweise auf LevelDB oder CouchDB basiert. Auf dieser wird der aktuelle Zustand der Blockchain gespeichert, um schnellere Transaktionsgeschwindigkeiten zu ermöglichen. CouchDB bietet gegenüber LevelDB den Vorteil, dass im Chaincode komplexere Querys abgefragt werden können, da es sich nicht um eine Key-Value Datenbank handelt. Der OABCS verwendet intern eine Oracle BerkeleyDB als State Datenbank, Abfragen sind jedoch über den Chaincode auch mithilfe von CouchDB Syntax möglich. Hierbei kann es jedoch zu kleinen Kompatibilitätsproblemen kommen, Oracle selbst empfiehlt in der Dokumentation die SQL rich query Syntax zu verwenden, falls der Chaincode ausschließlich auf dem Cloud Service betrieben wird. Andere Hyperledger Fabric Instanzen, auch für die lokale Chaincode Entwicklung, unterstützen die SQL rich query Syntax nicht. [3]

Fazit

Zusammengefasst ist zu sagen, dass der OABCS die Arbeit mit Hyperledger Fabric deutlich vereinfacht. Einmal eingerichtet bietet es deutlich mehr Komfort, sowohl für Chaincode Entwickler als auch für den finalen Betrieb.

 

Weiterführende Literatur:

Nitin Gaur, Luc Desrosiers et al. (2018): Hands-On Blockchain with Hyperledger. Packt Publishing

Quellen:

[1] Hyperledger Fabric Dokumentation https://hyperledger-fabric.readthedocs.io/en/release-1.4/blockchain.html

[2] Fabcar Beispiel auf Github https://github.com/hyperledger/fabric-samples/tree/release-1.4/fabcar

[3] Oracle Blockchain Cloud Dokumentation https://docs.oracle.com/en/cloud/paas/blockchain-cloud/user/query-state-database.html