Software Engineering

Continuous Delivery mit Hyperledger Fabric

Hyperledger Fabric?

Smart Contracts und Blockchain sind gefragte Themen. Durch diese intelligenten Verträge ist es möglich, Sicherheit und Vertrauen in ein Netzwerk zu bringen. Smart Contracts bieten viel Potential für Veränderungen in der Geschäftswelt. Das Framework Hyperledger Fabric wird für die Konzeption und Entwicklung von Smart Contracts verwendet. Es ist ein dezentrales System, welches die Daten verteilt bei jedem Teilnehmer im Netzwerk speichert.  Die Daten sind nicht durch einen einzelnen Teilnehmer manipulierbar, ohne dass andere Teilnehmer im Netzwerk die Änderungen erkennen. Es herrscht Konsens über die Daten und die Änderungen, die jeder Teilnehmer ausführen darf. Doch wie lässt sich Continuous Delivery mit Hyperledger Fabric kombinieren?

Wann ist ein Smart Contract Upgrade notwendig?

Ein Upgrade des Smart Contracts ist erforderlich, wenn der Vertrag aktualisiert bzw. geändert werden muss. Wie bei einem klassischen Vertrag ist dabei eine Änderung der Vertragsdetails zu vermerken. Das ist beispielsweise der Fall, wenn

  • eine externe Schnittstelle, auf die der Smart Contract zugreift, sich verändert
  • im Smart Contract ein Bug auftritt
  • neue Funktionalität hinzugefügt werden soll

Schritte einer Hyperledger Fabric Pipeline

Ein Chaincode (so wird ein Smart Contract bei Hyperledger Fabric genannt) wird, genau wie Standartsoftware, getestet. Dazu zählen u. a. Unittests, Akzeptanztests und Kapazitätstests. Im Anschluss erfolgt eine Codeanalyse mit bekannten Tools wie SonarQube, bevor die Pipeline ein Artefakt für die vereinfachte Chaincode Installation generiert. Nun folgt der Deploymentteil, wäre da nicht das Problem mit dem Konsens.

Herausforderung eines dezentralen Netzwerks

Die Chaincode ist bei Hyperledger Fabric nicht nur an einer zentralen Stelle, sondern an vielen Knotenpunkten im Netzwerk installiert. Das deployende System greift auf alle Knoten im Netzwerk zu, um die neue Version zu verteilen. Es handelt sich nicht mehr um ein verteiltes System, da es zentral gesteuert ist und die Netzwerkteilnehmer keine Kontrolle über den installierten Chaincode haben.

Um dieses Problem zu lösen lassen sich vier Lösungsansätze verfolgen, wobei jeder Ansatz seine eigenen Vor- und Nachteile hat:

  1. Jeder Teilnehmer führt sein Upgrade selbstständig durch
  2. Kein Upgrade („Code is law“)
  3. Eine zentrale Instanz führt ein Upgrade aus
  4. Eine Plattform, auf der Teilnehmer der über das Upgrade abstimmen, führt das Upgrade aus

Bewertungen der einzelnen Vorschläge

Ein eigenständiges Upgrade ist dabei am sichersten, da die Kontrolle über die eigenen Knoten im Netzwerk behalten wird und vor der Installation genau geprüft werden kann, was installiert wird. Dieser Lösungsvorschlag ist jedoch nicht stark automatisiert und dementsprechend langsam. Es handelt sich daher eher um eine Continuous Integration Pipeline, welche ein Artefakt erzeugt. Bei einer geringen Anzahl an Upgrades ist dieser Lösungsvorschlag in Betracht zu ziehen.

Der Ansatz kein Upgrade vorzunehmen ist im Blockchain Umfeld legitim, da streng genommen immer „Code is law“ gilt. Dafür ist jedoch weder eine Continuous Integration Pipeline noch eine Continuous Delivery Pipeline notwendig.

Wenn eine zentrale Instanz ein Upgrade ausführt, ohne die Netzwerkteilnehmer vorab zu fragen, ob sie mit diesem Upgrade einverstanden sind, ist der zentralen Instanz zu vertrauen, da diese auf alle deployenden Systeme zugreift. Der Vorteil dieses Lösungsansatzes ist die schnelle und stark automatisierte Installation von Upgrades, was im Falle eines Fehlers im Chaincode essentiell sein kann. Konsens ist dabei nicht gegeben.

Bei einer Continuous Delivery Pipeline mit manuellem Konsens Zwischenschritt wird dieser Konsens in Form einer Abstimmung über ein Chaincode Upgrade von den Teilnehmern abgefragt. Die Chaincode Installation wird angestoßen, wenn alle Teilnehmer dem Upgrade zustimmen und sich die Änderungen der neuen Version auf der Plattform anschauen. Die Abstimmung ist manipulationssicher, da die Stimme mit dem eigenen privaten Schlüssel signiert ist.

Eine Votingplattform im Detail

Ablauf einer Hyperledger Fabric Pipeline

Die Pipeline startet eine neue Abstimmung auf der Votingplattform, nachdem alle Tests erfolgreich durchgelaufen sind. Die Plattform kann entweder direkt im Smart Contract oder extern als eigenständiges System betrieben werden. Das Abstimmungsergebnis ist bei jeder Transaktion (Abstimmung) auf der Blockchain automatisch signiert. Bei einem externen System ist das Wahlergebnis mit den eigenen privaten Schlüsseln zu signieren. Nachdem alle Teilnehmer erfolgreich über ein Upgrade abgestimmt haben, stößt die Votingplattform das Deployment an. Um die Zugangsdaten aller Knoten im Netzwerk nicht an zentraler Stelle zu speichern, ist ein dezentrales Deployment vorzunehmen. Es ist ein zentrales, primäres Git Repository zu nutzen, auf dem die Entwicklung des Upgrades stattfindet. Das zentrale Repository ist lokal gespiegelt und der Chaincode wird installiert, falls es zu einem Upgrade kommt.

Fazit

Continuous Delivery mit Hyperledger Fabric ist komplex umzusetzen, da es sich um ein verteiltes Netzwerk handelt. Vor der Entwicklung einer Votingplattform ist zu schätzen, wie viele Upgrades in einem Hyperledger Fabric Netzwerk tatsächlich benötigt werden und ob ein manuelles, zeitaufwändiges Upgrade evtl. ausreicht. Die Pipeline ist durch einem externen Dienstleister zu betreiben, wenn alle Teilnehmer diesem vertrauen. Für Smart Contract Entwicklungszwecke ist eine Pipeline aufzusetzen, welche ein komplett neues Netzwerk deployed.

Weitere Infos zu Smart Contracts und Hyperledger sind in der offiziellen Hyperledger Fabric Dokumentation und im Buch Hands-On Blockchain with Hyperledger von Nitin Gaur u. a. verfügbar.