Der Markt für Blockchain-Lösungen wächst rasant. Research&Markets pro­gnostiziert, dass der globale Markt bis 2022 ein Volumen von 7,7 Milliarden Dollar erreichen wird. Das entspricht einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von bemerkenswerten 79,6 Prozent.

Blockchain-Technologie, auch als Distributed Ledger Technology (DLT) bezeichnet, ist dem Hype der Kryptowährungen entsprungen. Mittlerweile haben Blockchains diese Nische jedoch hinter sich gelassen. In einer Blockchain lassen sich zum Beispiel Ereignisse aus IoT-Sensorik protokollieren oder auf der Basis smarter Verträge steuern. Blockchain-Technologie erlaubt zudem die automatisierte Abwicklung von Geschäftstätigkeiten und Audits auf der Basis vordefinierter Regeln, auch unter Einbeziehung von Künstlicher Intelligenz. So bilden Blockchains den Grundpfeiler für eine Vielzahl von Anwendungen in Nutzungsszenarien, die mittlerweile nahezu die gesamte Wirtschaft umspannen.

An entsprechenden Blockchain-Plattformen und -Frameworks mangelt es nicht. Genauso wie die ihnen zugrunde liegenden Blockchains unterscheiden sich diese Lösungen in ihrem Funktionsumfang allerdings erheblich voneinander.

Doch wie funktioniert die Blockchain nun? Eine Blockchain, eine «Blockkette», ist im Wesentlichen eine verteilte Datenbank, die eine kontinuierlich wachsende Liste von Datensätzen, den Blöcken, mit Hilfe eines Konsensverfahrens verwaltet. Anders als herkömmliche Datenbanken steht bei Blockchains der Schutz der Daten vor Manipula­tionen im Vordergrund. Eine Blockchain oder Blockkette ist quasi ein verteiltes Kassenregister, über dessen Gültigkeit die berechtigten Nutzer zum Zeitpunkt der Eintragung neuer Transaktionen abstimmen. Stimmt das Kassenregister, wird die Blockchain mit Hilfe kryptografischer Algorithmen beglaubigt und repliziert.

Die verteilte, dezentrale Natur einer Blockchain sorgt für eine hohe Datenredundanz. Für die Gewährleistung der Datenintegrität ist das Konsensverfahren verantwortlich: Berechtigte Netzwerkknoten stimmen über den Zustand der Blockchain anhand der verfügbaren Replikas ab und können für ihre Wartungsaufgaben finanzielle Anreize erhalten. Das Resultat ist ein effizienter, autarker, dezentraler Datenspeicher mit der Fähigkeit zur Selbstheilung – und einem gewissen Poten­zial für Missbrauch.

Alle Blockchains fallen in eine von drei Ka­tegorien: Sie sind öffent­lich, privat oder Konsortium-kon­trolliert. Einige Frameworks unterstützen mehrere dieser Blockchain-Kategorien.

Öffentliche Blockchains: Sie bieten (auch) Nutzern ohne eine verifizierte Identität uneingeschränkt Zugang zu ihrer Funktionalität (anonymisiert/pseudonymisiert). So kann jeder Interessierte auf alle verfügbaren Informationen zurückgreifen, neue Transaktionen einreichen, über die Gültigkeit der Blöcke abstimmen und sich an der Wartung der Blockchain beteiligen. Um Missbrauch zu verhindern, kommen Mechanismen der Konsensbildung in Kombination mit wirtschaftlichen Anreizen (wie das Mining einer Kryptowährung) zum Einsatz. In vielen Szenarien ist ein öffentlicher Zugang zur Blockkette jedoch prinzipiell unerwünscht.

Private Blockchains: Sie beschränken den Zugang auf eine Gruppe berechtigter, bekannter Identitäten unter der Kon­trolle einer einzelnen Organisation. Typische Einsatz­gebiete für die private Blockchain sind das Dokumentenmanagement und das Nachverfolgen von Forschungsergebnissen.

Konsortium-kontrollierte Blockchains: Diese Mischform aus privaten und öffentlichen Blockchains beschränken den privilegierten Zugang zum gemeinsamen Ledger auf eine Gruppe berechtigter, bekannter Identitäten, doch anders als private Blockchains befinden sie sich nicht unter der Kontrolle einer einzelnen Organisation, sondern einer Gruppe verbündeter Unternehmen. Das soll das Vertrauen in die Fairness des Systems stärken. Konsortium-kontrollierte Blockchains nutzen eigene Verfahren zur Konsensbildung, die über vorab definierte Netzwerkknoten ablaufen (partiell dezentralisiert).

Eine hybride Blockchain kann externen Partnern den Zugang ermöglichen, um eine festgelegte Anzahl von Abfragen durchzuführen und Informationen zum Blockchain-Status abzufragen, während berechtigte Schreibzugriffe auf privilegierten notariellen Knoten ablaufen.

Die Kernaufgabe einer Blockchain-Engine besteht in der zuverlässigen und effizienten Konsensbildung zwischen dezentralen, autarken Teilnehmern des Blockchain-Netzwerks. Dabei handelt es sich um ein Verfahren zur Abstimmung des Zustands der gemeinsamen Blockchain und der Transak­tionsabwicklung. In der Art der Konsensbildung liegt ein wesentlicher Unterschied zwischen den verschiedenen Blockchain-Frameworks begründet. Für die Konsensfindung stehen verschiedene Mechanismen zur Verfügung: 

Proof of Work (PoW): Unter anderem bei Bitcoin, Litecoin und Ethereum 1.0 im Einsatz. Um neue Transaktionen registrieren zu können, müssen sich die betreffenden Teilnehmer, Miner genannt, durch die geleistete Rechenarbeit, das sogenannte Mining, qualifizieren. Diese Methode der Konsensfindung ist langsam, erfordert einen enormen Energieaufwand und führt letztlich zur Zentralisierung der Macht über das Netzwerk in der Hand weniger Mining-Pools.

Proof of Stake (PoS): Um neue Transaktionen registrieren zu können, müssen die validierungsberechtigten Teilnehmer, die Validators, eine Kaution in virtueller Währung als Nachweis ihres begründeten Interesses hinterlegen. Diese Methode der Konsensfindung ist energieschonender und schneller als PoW, begünstigt jedoch das Sparen und bremst die Zahlungsbereitschaft aus. PoS ist geplant für Ethereum 2.0 und 3.0.

Delegated Proof of Stake (DPoS): Hier wählen die Netzwerkteilnehmer in einer kontinuierlichen Abstimmung die sogenannten Witnesses. Nur die Witnesses dürfen die Transaktionsabwicklung bezeugen, einige dieser Nutzer bekommen für ihren Dienst eine Vergütung. Die Stimmrechte ergeben sich aus dem Wert der eingelegten Token.

Federated Byzantine Agreement (FBA): Dabei ist die Mitgliedschaft offen, die Steuerung ist dezentral, jedoch anstelle eines Quorums setzt das Verfahren auf Quorum-Slices – Untermengen der berechtigten Knoten. Die einzelnen Knoten suchen sich selbst aus, welchen Quorum-Slices sie vertrauen möchten. Die Quorum-Slices sollten sich vorzugsweise überlappen, um widersprüchliche Transaktionen, die gefürchtete Blockchain-Divergenz, zu vermeiden. So kommt der Konsensus dezentralisiert zustande. Im Übrigen ist es nicht erforderlich, dass jeder der Knoten vorab bekannt ist und auf seine Vertrauenswürdigkeit hin überprüft wurde.

Raft: Netzwerkknoten splitten sich in einen Leader und in Followers oder (falls kein Leader existiert) in Followers und Kandidaten für den Leader auf. Das Netzwerk benötigt einen Leader, um die Erstellung von Blöcken zu synchronisieren und ein Protokoll aufzuzeichnen. Followers ohne einen Leader bieten sich umgehend als Candidates an und halten eine Abstimmung ab, aus der ein Leader hervorgeht (die Knoten stimmen über den jeweiligen Zustand der Blockchain ab; so entsteht Konsensus). Dieser Knoten sendet dann ein Heartbeat-Signal an die übrigen Teilnehmer, solange er seine Aufgaben der Blockchain-Pflege wahrnehmen kann. Diese re­plizieren dann den aktuellen Zustand der Blockchain. Ein Beispiel für Raft ist das Hyperledger-Projekt Sawtooth.

Practical Byzantine Fault Tolerance (pBFT): Das pBFT-Modell verkraftet byzantinische Fehler, also die Aktivitäten böswilliger Knoten, unter der Annahme, dass unabhängige Knotenausfälle und manipulierte Nachrichten ganz bestimmten unabhängigen Knoten entstammen, die niemals mehr als (n-1)/3 aller Knoten ausmachen. Im Wesentlichen besteht das Netzwerk aus einem Primärknoten, dem Leader, und Sicherungsknoten (der Leader wechselt im Round-Robin-Verfahren). Alle Knoten innerhalb des Systems kommunizieren intensiv miteinander, wobei sie sowohl den Ursprung als auch die Inte­grität der Nachrichtenübertragung gegenüber dem jeweiligen Empfänger nachweisen müssen. Die ehrlichen Knoten erreichen dann einen Konsensus. Der Algorithmus wurde für asynchrone Systeme entwickelt. Bei einer geringen Anzahl von Knoten zeichnet pBFT sich durch eine hohe Leistung mit einer beeindruckenden Overhead-Laufzeit und einer nur geringen Latenzsteigerung aus. Es ist energieeffizienter als ein reines PoW-System, jedoch bei kleineren Netzen anfällig für Sybil-Attacken, bei denen ein Knoten viele andere Knoten manipulieren kann. Bei grösseren Netzen steigt wiederum der Overhead. pBFT eignet sich daher am besten für berechtigungspflichtige Blockchains; in öffentlichen Blockchains kommt es in einer hybriden Implementierung zum Einsatz. Genutzt wird pBFT zum Beispiel bei den Hyperledger-Lösungen Fabric und Sawtooth.

Andere erwähnenswerte Konsensus-Algorithmen sind Hedera Hashgraph (aBFT-Consensus) und Intels Proof of Elapsed Time (PoET).

Eine Vielzahl von Blockchain-Anwendungen sind quell­offen. Sie liegen etwa auf Github und lassen sich nach Belieben ausprobieren und anpassen. Gängige Implementierungen von Software-Lösungen auf Blockchain-Basis setzen sich im Wesentlichen aus folgenden Elementen zu­sammen: 

Im ersten Konzept der DLT-Technik – erstellt von Satoshi Nakamoto – entstand eine Blockchain, die nur Transaktionen ohne jegliche Zusatzbedingungen protokollieren konnte. Smarte Verträge, mit die reizvollste Ausprägung eines Blockchain-Ökosystems, sind inzwischen aber ein Kernbestandteil nahezu aller Blockchain-Frameworks, von Ethereum über Hyperledger Sawtooth bis hin zu MultiChain.

Bei smarten Verträgen handelt es sich um ausführbaren Code, der Blockchain-Transaktionen anhand zusätzlicher Daten über die Erfüllung vorgegebener Bedingungen verarbeiten kann. So ist es etwa möglich, Ereignisse anhand von Messwerten aus IoT-Sensorik zu protokollieren, um automatische Zahlungen im Rahmen von Vertragsbedingungen softwaregesteuert auszulösen. Smarte Verträge bilden die interne Transaktions-Engine von Ethereum, einem der führenden Blockchain-Frameworks. Ethereum bietet eine robuste Implementierung von smarten Verträgen als ausführbaren Code für die Ethereum Virtual Machine, zum Beispiel in Solidity oder Vyper.

Die Ethereum-Plattform ermöglicht neben dem Aufbau dezentraler Anwendungen das Einrichten und Ausführen von DAOs (dezentralen autonomen Organisationen) auf der Basis smarter Verträge. Dabei handelt es sich im Wesentlichen um wirtschaftliche Entitäten, die in Software konzipiert sind. Sie verfügen über digitale Vermögenswerte oder sonstige Rechte ihrer Teilnehmer, um diese Ressourcen unter Verwendung von smarten Verträgen zu verwalten und zu nutzen. Eigentümer der eingelegten Token können über das Schicksal ihrer DAOs abstimmen.

Die Ethereum-Blockchain nutzt aktuell das Proof-of-Work-Konsensverfahren. Neue Blöcke entstehen durch aufwendiges Proof-of-Work-Mining. Jeder Knoten des Ethereum-Netzwerks muss jede Transaktion validieren. Dieses Verfahren hat das Volumen reduziert und die Transaktionsabwicklung verlangsamt. Die Netzwerkgebühren zur Vergütung der Miner rechnet Ethereum in «Gas» ab, einer Einheit zum Messen der Compute-Aufwendungen für die Ausführung von Transaktionen, die Verarbeitung von smarten Verträgen und andere Operationen auf Ethereum.

Öffentliche Blockchains, darunter Ethereum, leiden derzeit an akuten Skalierbarkeitsproblemen. Die vergleichsweise langsame Verarbeitung von Code auf Ethereum disqualifiziert das Framework für viele Anwendungen und stärkt das Interesse an Alternativen. Dennoch hat sich die Anzahl von Transaktionen pro Tag auf Ethereum allein in den letzten zwei Jahren bis Anfang 2019 mehr als verzehnfacht. Die Konsensbildung via Proof of Work erweist sich bei dieser Netzwerkgrösse als entschieden zu teuer und nicht hinreichend zuverlässig. Nicht einmal TrueBit, ein vielversprechendes Protokoll für Off-Chain-Berechnungen in WebAssembly-Byte­code zur Unterstützung der Parallelisierbarkeit von smarten Verträgen, kann das grundlegende Problem des Ethereum-Frameworks auf Dauer lösen.

Abhilfe schaffen soll Ethereum 2.0 mit einem neuen Konsensprotokoll. Drei grundlegende Verbesserungen sollen die Problematik der Skalierbarkeit angehen:

Das vorgeschlagene Blockchain-Sharding soll über die sogenannte zufällige Beacon Chain implementiert werden. Diese Side-Chain soll Validator-Knoten verwalten und die daraus resultierenden Shard-Zustände abgleichen. Derzeit befindet sie sich noch in der Entwicklung. Sharding dürfte die Leistung des Ethereum-Frameworks erheblich verbessern.

Die wichtigste Aufgabe der Beacon Chain besteht darin, die Konsensbildung via Proof of Stake ausserhalb der aktuellen Blockchain (also ohne Hard-Fork) zu ermöglichen; hier sollen die Casper-Validators mit ihren hinterlegten Deposits für die Gültigkeit der von ihnen beglaubigten Blöcke bürgen. Validators müssen hierzu jeweils mindestens 32 Ether (rund 8600 Schweizer Franken) aus der PoW-Chain (dem aktuellen Mainnet) auf die Beacon Chain übertragen und in einem smarten Vertrag aufbewahren. Die Beacon Chain wird dann auf die verschiedenen Shard Chains verzweigen und nach neuen Blöcken lauschen.

Die Shards sollen eine höhere Skalierbarkeit der Ethereum-Blockchain und die Parallelisierbarkeit der Transaktionsabwicklung ermöglichen. Sie verfügen jeweils über eine eigene Rückverlinkung auf die Beacon Chain. Diese muss zur Übertragung der Blöcke in die Beacon Chain durch eine Gruppe zufällig gewählter Validators des jeweiligen Shards zertifiziert werden. Die Ethereum-Gemeinde verspricht sich von Casper eine höhere byzantinische Fehlertoleranz der Blockchain. Casper sanktioniert unehrliche Validator-Knoten und manipulative Teilnehmer, indem das Protokoll die eingelegten Deposits einzieht.

Hyperledger Fabric entstammt den Entwicklungslaboren von IBM. Das Framework dient als Grundlage für die Entwicklung dezentraler Anwendungen im Unternehmensumfeld auf Basis einer berechtigungspflichtigen Blockchain. Der Kern der Plattform ist in Go geschrieben.

Die modulare Architektur von Fabric erlaubt die Einbindung von Konsens-, Mitgliedschafts- und anderen Services als ladbaren Modulen. Ein einzigartiges Merkmal von Fa­bric ist das Konzept der privaten Kanäle (nach dem Vorbild privater Chats). Hyperledger Executive Director Brian Behlendorf bringt das Feature so auf den Punkt: «Wenn Sie über ein grosses Blockchain-Netzwerk verfügen und Daten nur mit bestimmten Parteien teilen möchten, können Sie einen privaten Kanal nur mit diesen Teilnehmern erstellen.»

Hyperledger Sawtooth entstand aus dem Projekt Sawtooth Lake von Intel und wird derzeit unter dem Dach der Hyperledger Foundation unter einer Apache-2.0-Lizenz weiterentwickelt. Das Framework unterstützt sowohl berechtigungsfreie als auch berechtigungspflichtige Blockchains. Es skaliert auf sehr grosse Netze und ist stark auf Agilität hin ausgerichtet. Der Funktionsumfang von Hyperledger Sawtooth enthält grundlegende Funktionen wie die Steuerung der Kommunikation zwischen Knoten in einem Netzwerk, das Speichern von Daten in der Blockchain und die Handhabung von smarten Verträgen und Konsensalgorithmen. Als einziges der führenden Blockchain-Frameworks lässt es sich dynamisch zur Laufzeit erweitern.

Sawtooth sichert persistente Daten im On-Chain-Schlüsselwertspeicher, einem binären verteilten Speicher, der allen Validator-Knoten zur Verfügung steht. Die Daten lassen sich mit Hilfe von Transaktionen verändern. Jede Transaktion gehört hierbei zu einer sogenannten Transaktionsfamilie und wird mit Hilfe des zugehörigen Handlers verarbeitet. Der Handler einer Transaktionsfamilie nimmt den Payload der Transaktion entgegen, analysiert diesen, führt die erforder­liche Geschäftslogik aus und schreibt die notwendigen Änderungen in den Speicher.

Anders als im Fall von Blockchain-Frameworks wie Ethereum kann Sawtooth Smart-Contracts-Code in beliebigen Programmiersprachen verarbeiten und ausserhalb der Blockchain aufbewahren. Anstatt den Code der smarten Verträge mit der Blockchain zu verteilen, muss jeder Validator-Knoten eine Software installieren, um die smarten Verträge ausführen zu können.

Blockchain-Frameworks bieten reichlich Potenzial für die Entwicklung innovativer Lösungen, die auf massive Rechenleistung zurückgreifen. Eine geeignete Umgebung dafür ist die Cloud. Blockchain-Technologie wurde bisher im unternehmenseigenen Data-Center realisiert, in der Krypto-En­gine des verteilten Ledgers. Doch mit dem Aufkommen von Blockchain-as-a-Service-Angeboten in der Cloud (BaaS) haben Blockchain-Entwickler neue Optionen zur Anbindung ihrer dezentralisierten Apps, kurz DApps, hinzugewonnen.

Microsoft Azure hat sich im Lauf der letzten Jahre zum Blockchain-Technologieführer entwickelt und zunächst einen Blockchain-as-a-Service-Dienst namens EBaaS (Ethereum Blockchain as a Service) zur Entwicklung von Prototypen öffentlicher smarter Verträge auf Basis der Ethereum-Blockchain vorgestellt. In der ersten Implementierung fehlte der Plattform jedoch noch die Fähigkeit der Rechteverwaltung, weswegen Entwickler nicht viel damit anfangen konnten.

Microsoft ging mit der Wunschliste der Azure-Nutzer zurück ans Reissbrett und optimierte den Dienst weiter. Das Resultat ist ein ganzes Ökosystem von Blockchain-Lösungen auf Microsoft Azure: mehrfach vernetzte Konsortium-kontrollierte Blockchains und das leistungsstarke Framework Coco für hochskalierbare, vertrauliche, Konsortium-kontrollierte Blockchain-Netzwerke auf Azure. Inzwischen können Azure-Nutzer ausser Ethereum auch andere Blockchain-Netzwerke in der Cloud aufsetzen, da­runter zum Beispiel Quorum (EEA), Hyperledger Fabric, R3 Corda und Chain Core.

Darüber hinaus ist es auf Microsoft Azure möglich, private, öffentliche und Konsortium-kontrollierte Blockchain-Ökosysteme gleichermassen im Produktivbetrieb zu nutzen. Letzteres war die eigentliche Herausforderung. Konsortium-kontrollierte Netzwerke benötigen nämlich Fähigkeiten zur verteilten Verwaltung der Blockchain durch mehrere Handelspartner unter Gewährleistung einer erhöhten Vertraulichkeit.

Der Azure-Betreiber sieht den grössten Nutzen der Blockchain-Technologie im Bereich der Cybersicherheit, und zwar im Zusammenhang mit Identitäts-Management und Verschlüsselung, beides Voraussetzungen für den Einsatz im Unternehmensumfeld. In Zusammenarbeit mit Accenture und anderen Mitgliedern der Decentralized Identity Foundation experimentieren die Redmonder mit der Blockchain als Grundlage für ein cloudbasiertes System zur sicheren Verwaltung dezentralisierter digitaler Identitäten (DIDs). Im Rahmen dieser Zusammenarbeit entsteht unter anderem ein verschlüsselter Data-Store für dezentralisierte Identitäten und ein Server namens Universal DID Resolver, der zwischen DIDs verschiedener Blockchains vermitteln soll, zum Beispiel im Rahmen der Microsoft-eigenen App Authenticator.

In dem von Microsoft avisierten Design soll die ID eines Benutzers in der Blockchain verankert sein, während die eigentlichen Identitätsdaten ausserhalb der Blockchain im sogenannten ID-Hub in verschlüsselter Form gesichert werden. Hier sind die Daten selbst für Microsoft unzugänglich.

Die Führungsrolle von Azure ist nicht lange unangefochten geblieben. Vor allem AWS hat nachgezogen. Amazon möchte sich dabei eigenen Aussagen zufolge nicht auf ein bestimmtes Protokoll oder eine bestimmte Blockchain-Plattform festlegen lassen. Man strebe vielmehr ein Ökosystem an, das möglichst beliebige Nutzungsszenarien in einer Vielzahl von Branchen unter einen Hut bringen könne. AWS arbeitet unter anderem mit T-Mobile, den Consulting-Agenturen PwC und Deloitte und der Venture-Capital-Firma Digital Currency Group zusammen. Derzeit können Entwickler ihre Blockchain-Laufzeitumgebung für Ethereum oder Hyperledger Fabric unter Verwendung von AWS-Blockchain-Templates als Container auf ECS oder als Docker-Container auf EC2-Instanzen aufsetzen.

Die Lizenzbedingungen im Rahmen eines Software-Stacks beziehungsweise Ökosystems von Blockchain-basierten Lösungen zählen zu den Themen, mit denen sich Entwickler von Anfang an bewusst auseinandersetzen sollten. Denn bei derart verzahnten Stacks wie Blockchain-Software ist das nachträgliche Ändern einer Lizenz nicht bloss mühsam, sondern im Grunde unmöglich. Dies liegt in der grossen Zahl der Beteiligten begründet, die einen Beitrag geleistet haben, sich gegenseitig nicht kennen und ihre Zustimmung stillschweigend verweigern könnten.

Lizenzkonflikte sind in der Blockchain-Szene also vorprogrammiert und extrem problematisch. So trugen sich beispielsweise die Entscheider bei Hyperledger eine Zeit lang mit dem Gedanken, Projekte zu hosten, die sich in der Rolle eines Clients an die Ethereum-Kette anbinden oder auf der Ethereum-Plattform aufbauen würden. So könnte sich Hyperledger auf das Ethereum-Protokoll stützen und einen De-facto-Standard für Blockchains küren.

Die Integration angeregt hatte Ethereum-Erfinder Vitalik Buterin. Die Hyperledger-Gemeinde zeigte sich der Idee gegenüber entsprechend aufgeschlossen. Um die Zusammen­arbeit zu festigen, sollte Ethereum C++ (cpp-ethereum) in Hyperledger einfliessen. Dieses Vorhaben liess sich lizenzkonform aber nicht realisieren. Die Nutzungsbedingungen der beiden Projekte waren nämlich aufgrund der Verwendung unterschiedlicher Open-Source-Lizenzen inkompatibel miteinander. Ethereum C++ wurde unter der GPLv3 lizenziert, während Hyperledger Apache 2.0 verwendet. Die Integration von Ethereum C++ in Hyperledger hätte eine Neu-Lizenzierung des Ethereum-C++-Clients – mit Zustimmung jedes einzelnen Entwicklers – auf Apache 2.0 erforderlich gemacht. Die Zusammenarbeit ist an den vielfältigen Komplexitäten dieses Vorhabens letztendlich gescheitert. Für beachtliche Teile des Ethereum-Ökosystems sind die Lizenzbedingungen immer noch nicht eindeutig spezifiziert, sie neigen jedoch zu einer restriktiven Auslegung; da darf man sich über das Ergebnis nicht wundern. Die Schlussfolgerung lautet also: Drum prüfe, wer fremden Code in Lizenz nutzt – bei Blockchain-Lösungen umso genauer.

Hyperledger hostet derzeit unter anderem Fabric (das Flaggschiff-Framework für Blockchain-Lösungen), Sawtooth Lake (eine innovative Blockchain mit modularen Transak­tionsfamilien) und Iroha (eine quelloffene Blockchain-Plattform für vertrauenswürdige, schnelle und sichere Anwendungen mit byzantinischer Fehlertoleranz), von Ethereum gibt es hier praktisch keine Spur. Hinzu kommt noch ein weiterer, Blockchain-spezifischer Aspekt von Software-Lizenzen: das Aufkommen von hybriden Lizenzen wie JLP (Jelurida Public License), einer Coinleft-Lizenz. Basierend auf der GNU GPL fügt sie ihrem Copyleft-Unterbau eine zusätzliche Anforderung hinzu: Für die Verwendung der Nxt-Software für den eigenen Code müssen Entwickler 10 Prozent der Coins, die sie erzeugen, per Airdrop an die Nxt-Entwicklergemeinde übertragen.

Die Wahl des Blockchain-Frameworks hat weitreichende Konsequenzen. Sie beeinflusst die Leistungsfähigkeit der darauf aufbauenden Lösungen, bestimmt die zulässigen Methoden der Konsensbildung, die Herausforderungen der Inter­operabilität und den gebotenen Grad an Cybersicherheit.

Zu bedenken ist etwa, dass sich nach der Entscheidung für ein kommerzielles Framework die Entwicklung der Lizenzkosten niemals wirklich vorhersagen lässt. Ein proprietäres Framework mit einer kommerziellen Lizenz kann deshalb leicht das Aus für das Blockchain-Projekt bedeuten. Und selbst Grossunternehmen machen um kommerzielle Blockchain-Frameworks oft einen grossen Bogen, weil sich ein kostenpflichtiges Lizenzmodell in vielen Fällen negativ auf die Grösse und das Wachstum einer Entwicklergemeinde auswirkt.

Eine Herausforderung beim Umgang mit der Blockchain ist für interessierte Unternehmen nicht zuletzt die übergrosse Auswahl an Frameworks. Die nachstehende PDF-Datei stellt daher die wichtigsten Blockchains und ihre Eigenschaften vor.