München und/oder Köln? BLOCKCHAIN-GRUNDLAGEN Die Rätselkette. SCHWERPUNKT Blockchains

Transkript

1 Foto: Shutterstock / Zapp2Photo SCHWERPUNKT Blockchains BLOCKCHAIN-GRUNDLAGEN Die Rätselkette Hype oder Revolution? Über die dezentrale Datenbank, die das Rückgrat der digitalen Währung Bitcoin bildet, wird viel diskutiert. Was versteckt sich dahinter? U m zu verstehen, was Blockchains sind, welche Eigenschaften sie haben und was sie so besonders macht, schauen wir uns zunächst an, welche Probleme mit ihnen gelöst werden sollen. Heute speichern Unternehmen ihre Daten in der Regel in Datenbanken, die durch verschiedene Sicherheitsmechanismen vor unbefugtem Zugriff geschützt sind. So wird zum Beispiel durch Benutzername und Kennwort sichergestellt, dass nur die Personen Zugriff auf die Datenbasis haben, die auch tatsächlich dazu berechtigt sind. Außerdem wird der Datenbankserver geschützt, das gesamte Netzwerk, in dem sich der Datenbankserver befindet, und so weiter. Die Datenbank wird also innerhalb von vertrauenswürdigen Grenzen gehalten und eine Überschreitung dieser Grenzen durch Externe ist nicht ohne Weiteres möglich. Für viele rein interne Anwendungsfälle ist das meist auch ausreichend, kompliziert wird es jedoch, wenn mit Externen zusammengearbeitet werden soll. 12 München und/oder Köln? Nehmen wir als Beispiel zwei Verkehrsbetriebe, einen in Köln und einen in München: Beide bieten grundsätzlich den gleichen Dienst an, nämlich die Personenbeförderung mit Bussen und Bahnen. Wenn ich als Kunde eine Monatskarte für die Busbeförderung habe, dann gilt diese meistens regional begrenzt, zum Beispiel nur in Köln. Als Kunde möchte ich aber vielleicht auch die Dienstleistung des Verkehrsbetriebs in München mit der Monatskarte in Anspruch nehmen. Lassen wir mal für einen Moment die unterschiedlichen Tarife, Strecken und Interessen der Verkehrsbetriebe außer Acht und überlegen uns einfach, was passieren müsste, damit ich mein Monatsticket deutschlandweit einsetzen kann. Der Verkehrsbetrieb in Köln hat alle Informationen über mich, die er braucht, um den monatlich fälligen Betrag von meinem Konto einzuziehen. Der Verkehrsbetrieb in München muss nur die von mir getätigten Fahrten melden und

2 könnte dann anteilig an dem von mir entrichteten Monatsbeitrag beteiligt werden. Da jeder Verkehrsbetrieb nun aber seine eigene Datenbank innerhalb der gezogenen Vertrauensgrenzen betreibt, ist der Datenaustausch zwischen den beiden nicht so einfach. Wenn ich zum Beispiel meine Fahrt in München antrete und meine Monatskarte präsentiere, müsste in der Datenbank in Köln nachgeschlagen werden, ob ich überhaupt berechtigt bin; vielleicht habe ich ja meinen Monatsbeitrag nicht bezahlt oder mein Vertrag ist ausgelaufen. Hinterher müsste gemeldet werden, wie weit ich gefahren bin, damit der Verkehrsbetrieb den richtigen Anteil an meinem Monatsbeitrag erhält. Hier müsste sichergestellt sein, dass auch wirklich die richtige Strecke gewählt wird, und nicht etwa eine, die etwas länger ist und den Verkehrsbetrieb in München begünstigt. Außerdem muss sichergestellt sein, dass nicht mehr Fahrten gemeldet werden, als tatsächlich durchgeführt wurden. Clearingstelle als Mittelsmann Bereits die anfängliche Überprüfung meiner Fahrberechtigung würde erfordern, dass man aus München auf den Datenbestand in Köln zugreifen kann. Und da natürlich jemand mit einer Monatskarte in München auch in Köln fahren möchte, muss das auch andersherum möglich sein. Außerdem möchte man vielleicht nicht nur in München oder Köln fahren, sondern auch in Hamburg, Berlin und so weiter. Kurzum: Immer nur einen bidirektionalen Datenzugriff zwischen zwei Verkehrsbetrieben einzurichten sprengt den Rahmen des Machbaren. Heute behilft man sich in solchen Szenarien üblicherweise dadurch, dass man sogenannte Clearingstellen einsetzt, die die notwendigen Daten regelmäßig über definierte Schnittstellen von allen beteiligten Stellen einsammeln und dann wiederum an alle Stellen bedarfsgerecht verteilen. In unserem Beispiel der Verkehrsbetriebe würde also die Clearingstelle die Fahrtberechtigung prüfen, anschließend den Datensatz über die durchgeführte Fahrt speichern und dann zum Beispiel am Monatsende das Geld zwischen allen Verkehrsbetrieben aufteilen. Wenn nun ein neuer Verkehrsbetrieb seine Dienste anbieten möchte, muss er nicht mehr die Schnittstellen mit allen anderen Unternehmen austauschen, sondern sich nur der Clearingstelle anschließen. Diese Clearingstelle genießt dabei das Vertrauen aller beteiligten Unternehmen, das heißt, sie stellt sicher, dass die dort verwalteten Daten auch korrekt sind, also zum Beispiel kein Abrechnungsbetrug möglich ist. Dazu führt sie eine Kopie der Daten, die für Abrechnung und Koordination benötigt werden. Solche Datenkopien haben natürlich den Nachteil, dass dezentral gespeicherte Daten konsistent gehalten werden müssen, die Datenbanken auch wieder abzusichern sind, separate Verfahren zur Einhaltung des Datenschutzes umgesetzt werden müssen und so fort. oder zentrale Datenbasis Ein Ansatz, diese Komplexität in den Griff zu bekommen, wäre es, wenn alle Verkehrsbetriebe nicht mehr verschiedene Datenbanken nutzen würden, sondern alle auf eine zent- Sind alle Transaktionen für die Beteiligten transparent, kann die Clearingstelle als Mittelsmann entfallen (Bild 1) rale Datenbasis zugreifen würden. Natürlich könnte man den gesamten Datenbestand unterteilen, sodass meine persönlichen Kontodaten beispielsweise nur bei meinem Verkehrsbetrieb liegen und alle Fahrberechtigungen und getätigten Fahrten pseudonymisiert in einer gemeinsamen, großen Datenbank abgelegt werden. Statt also viele einzelne Datenbanken mit unterschiedlichen Datenständen zu haben, nutzen immer alle die gemeinsame Datenbank. Die regelmäßige Synchronisation von Daten zwischen den einzelnen Stellen würde nun entfallen und damit auch die Komplexität, die mit der doppelten Datenhaltung einhergeht. Da immer alle die Datenbank der anderen Verkehrsbetriebe einsehen können, kann außerdem eine regelmäßige Buchprüfung aller beteiligten Unternehmen durchgeführt werden, sodass der Abrechnungsbetrug untereinander dadurch verhindert wird, dass alle Beteiligten jederzeit in die Bücher der anderen gucken könnten. Wenn ein neuer Verkehrsbetrieb hinzukommt, muss er sich nicht mehr mit allen anderen Beteiligten einzeln auseinandersetzen und Schnittstellen aushandeln, sondern er kann sich einfach der Datenbank anschließen. Wenn nun alle die gleiche Datenbasis besitzen, kein Datenaustausch mehr nötig ist und das Vertrauen dadurch entsteht, dass jeder jederzeit alle Transaktionen auf Korrektheit prüfen kann, dann kann man sich die Frage stellen, wozu man überhaupt noch die Clearingstelle als Mittelsmann braucht. Die intuitive Antwort darauf lautet: Irgendwer muss ja auch diese zentrale Datenbank betreiben und koordinieren. Die Antwort könnte aber auch lauten: Die Clearingstelle braucht man gar nicht mehr, wenn die zentrale Datenbank eine Peer-To- Peer-Datenbank wäre, bei der keinem die Datenbank allein gehört, sondern jeder Teilnehmer zu jeder Zeit eine vollständige, konsistente Kopie der Daten hat (Bild 1). Wie ein Distributed Ledger helfen kann Genau das ist die Idee hinter der sogenannten Distributed- Ledger-Technologie (DLT), also einem verteilten Transaktions protokoll. Da diese Peer-to-Peer-Datenbank so lange weiterexistiert, wie noch eine einzige Instanz aktiv ist, sie also keinem Einzelnen gehört, der die Kontrolle über den Lebenszyklus hat, spricht man manchmal auch von Shared Distributed Ledger, also einem gemeinsamen, verteilten Transaktionsprotokoll. Bei der DLT wird eine logisch zentrale Datenbank aller angefallenen Transaktionen aufgebaut, die aber technologisch über alle Knoten in einem Peer-to-Peer-Netzwerk verteilt ist. Alle Knoten in diesem Netzwerk besitzen den gleichen Da

3 tenbestand, und jede neue Transaktion wird immer an alle Knoten verteilt. Das hört sich sehr trivial an, jedoch muss man in einem solchen dezentralen System immer davon ausgehen, dass einzelne Knoten (bewusst oder unbewusst) Fehler produzieren. Man kann mathematisch zeigen, dass in einem dezentralen System eine Einigung über die Korrektheit von Transaktionen nur unter bestimmten Bedingungen erfolgen kann (wird oft als Problem der byzantinischen Generäle bezeichnet). Die Aufgabe der DLT ist nun, sicherzustellen, dass fehlerhafte Transaktionen erkannt werden und nicht den Weg in das Transaktionsprotokoll finden. Der gemeinsame Konsens Üblicherweise ist eine weitere Eigenschaft der DLT, dass das Transaktionsprotokoll unveränderlich ist, das heißt, einmal erfasste Transaktionen können nicht mehr gelöscht werden. Es muss, vergleichbar mit der ordentlichen Buchhaltung, immer eine dokumentierte Gegenbuchung erfolgen, um eine Transaktion rückgängig zu machen. Für unser Beispiel bedeutet das, dass jeder Verkehrsbetrieb eine Kopie aller Daten besitzt und neue Fahrten aber erst als gültig und abrechenbar akzeptiert werden, wenn es einen Konsens unter den Beteiligten gibt, dass diese auch gültig sind. Dieses Verfahren wird als Consensus bezeichnet, und später lernen wir noch kennen, wie verschiedene Systeme diesen Consensus umsetzen. Damit jetzt nur Verkehrsbetriebe auf die Datenbank zugreifen können und nicht etwa unbeteiligte Dritte, wird diese Datenbank wieder abgesichert. So wird zum Beispiel über übliche Methoden wie etwa Authentifizierung oder Verschlüsselung sichergestellt, dass nur berechtigte Parteien an dem Peer-to-Peer-Protokoll teilnehmen können. In einem solchen Fall spricht man häufig auch von einem Enterprise Consortium Network, das heißt einem Netzwerk, das explizit den Mitgliedern eines Konsortiums vorbehalten ist. Rund um das Thema DLT haben sich in den letzten Jahren und Monaten eine Menge solcher Konsortien gebildet, unter anderem das B3i-Konsortium verschiedener großer Versicherungen oder R3, in dem sich neben verschiedenen Banken auch Unternehmen wie Toyota und Microsoft wiederfinden. Wenn man also über DLT spricht, spricht man nicht über eine konkrete Implementierung einer dezentralen Datenbank, sondern eher von dem Konzept der Kombination aus Peer-to-Peer-Netzwerken, dem Consensus-Verfahren, der Unveränderlichkeit des Transaktionsprotokolls und der Tatsache, dass die Datenbank von keinem einzelnen Unternehmen kontrolliert oder betrieben wird, sondern gleichermaßen (und in der Regel gleichberechtigt) von allen Mitgliedern eines bestimmten Kreises. Die Implementierung erfolgt dann üblicherweise nicht auf Anwendungsebene, zum Beispiel für die Speicherung eines Monatstickets, sondern eher auf einer Protokollebene zum Austausch beliebiger Transaktionen. So kann die Datenbank auch für beliebige zukünftige Anwendungsfälle genutzt werden. Dies ist sicherlich ein großer Unterschied zu heutigen vergleichbaren Umsetzungen, wo bei der Zusammenarbeit von zwei oder mehr Unternehmen zum Beispiel konkrete Webschnittstellen für die Abwicklung bestimmter Geschäftsvorfälle definiert werden. Von der DLT zur Blockchain Der Aufbau eines Distributed Ledger innerhalb eines Konsortiums erscheint nun nicht so kompliziert, denn die Vereinbarung von Protokollen zum Datenaustausch und die Sicherung des Zugangs können zwischen den Mitgliedern abgestimmt werden. Man kennt sich, es können Verträge geschlossen werden und man vertraut sich bis zu einem gewissen Grad auch; immerhin möchte man gemeinsame Geschäfte abwickeln. Das Revolutionäre entsteht eigentlich, wenn man sich Szenarien vorstellt, bei denen Geschäftsprozesse abgewickelt werden können, bei denen sich die Beteiligten weder kennen noch vertrauen. Nehmen wir ein einfaches Beispiel mit dem Kauf von Musik: Wenn ich ein Smartphone besitze und ein Musikalbum kaufen möchte, habe ich einen Zwischenhändler, der zwischen mir als Käufer und dem eigentlichen Anbieter, dem Musiker, vermittelt. Dieser Zwischenhändler stellt sicher, dass ich nur dann auf die Musik zugreifen kann, wenn die Zahlung dafür erfolgreich abgewickelt wurde. Der Musiker und ich, wir müssen beide dem Zwischenhändler vertrauen, aber wir müssen uns selbst weder kennen noch vertrauen. Der Zwischenhändler erhält seine Provision also nur für die Vermittlung einer Leistung (natürlich macht er häufig noch mehr, zum Beispiel spricht er personalisierte Musikempfehlungen aus). Was wäre nun, wenn ich wie im Beispiel mit den Verkehrsunternehmen versuchen möchte, diesen zentralen Zwischenhändler herauszunehmen? Wie stellen wir dann sicher, dass der Musiker und ich ein sicheres Geschäft abwickeln können, ohne dass wir einander kennen oder vertrauen können? Mit einer Blockchain ist so etwas möglich, und die Krypto-Währung Bitcoin (ursprünglich konzipiert von Satoshi Nakamoto, von dem bis heute keiner weiß, wer das eigentlich ist) ist ein gutes Beispiel dafür: Hier können Teilnehmer, die sich nicht kennen oder vertrauen, relativ einfach weltweit Geld transferieren, ohne dass es dazu einer Bank oder eines anderen Mittelsmanns bedarf. Etwas Kryptografie Um zu verstehen, wie das bei Bitcoin (und vielen anderen Blockchains) umgesetzt wird, müssen wir etwas tiefer in die Kryptografie einsteigen. Fangen wir dazu mit einer einfachen Bitcoin-Transaktion an, bei der wir einen bestimmten Betrag, gemessen in Bitcoin (BTC) und Satoshi, an eine andere Person überweisen (ein Satoshi entspricht dabei 10-8 BTC, das heißt 0, BTC). Alles, was ich dafür kennen muss, ist die Adresse meiner sogenannten Wallet auf der Blockchain, das heißt des Portemonnaies, in dem ich meine Bitcoins aufbewahre, und die Adresse der Wallet, die die Bitcoins empfangen soll. Ich kann dabei nur dann Bitcoins aus meiner Wallet versenden, wenn ich vorher welche empfangen habe und

4 Zusammenfassung der Transaktionen in Blöcken (Bild 2) ich über einen geheimen Schlüssel verfüge, mit dem ich die Entnahme autorisieren kann. Diesen Private Key muss ich also ebenfalls kennen, und die Bezeichnung suggeriert schon, dass hinter Bitcoin asymmetrische Kryptografie steckt. Da Bitcoin vom Konzept her die Eigenschaft eines DLT teilt, bedeutet das auch, dass jeder Teilnehmer sehen kann, wie viele Bitcoins sich derzeit in der Wallet mit einer bestimmten Adresse befinden. Aber niemand kann ohne Weiteres darauf schließen, welche Person sich hinter einer Wallet verbirgt (es ist aber ein mittlerweile widerlegter Irrglaube, dass Bitcoin vollständig anonym sei). Eine einfache Transaktion, die wir nun unveränderlich in unserem Transaktionsprotokoll ablegen wollen, besteht im einfachsten Fall aus Quelladresse, Zieladresse und Betrag. Ich muss nun die Transaktion noch mit meinem privaten Schlüssel signieren und kann diese dann an alle Knoten im Netzwerk senden. Da jeder Knoten alle Transaktionen und Wallets kennt, kann jetzt jeder Knoten sehr einfach prüfen, ob sich in meiner Wallet noch ein ausreichend hoher Betrag befindet und ob die Signatur darauf schließen lässt, dass die Transaktion auch wirklich von dem Besitzer der Wallet autorisiert wurde. Wenn beides stimmt, kann die Transaktion als $ $ Hash-Funktionen Hash-Funktionen sind mathematische Funktionen, in denen Zeichenketten beliebiger Länge auf eine Zeichenkette mit definierter Länge abgebildet werden. Wenn man die Ausgabe dieser Funktion kennt, kann man allerdings nicht auf den Eingangswert schließen. Außerdem erzeugen zwei ähnliche Eingangswerte zwei komplett unterschiedliche Ausgangswerte, und zwei ähnliche Ausgangswerte entsprechen komplett unterschiedlichen Eingangswerten. Hash-Funktionen eignen sich daher in der Kryptografie gut für digitale Signaturen, mit denen zum Beispiel die Manipulation von Dokumenten und Transaktionen aufgedeckt werden kann. gültig in das Transaktionsprotokoll aufgenommen werden und das Geld wurde übertragen. Dadurch, dass die Transaktion dauerhaft und unveränderlich in der Blockchain erfasst wurde, wird ein grundlegendes Problem gelöst, nämlich das sogenannte Double-Spending- Problem. Anders als bei Geldscheinen, die sich nicht mehr in meinem Besitz befinden, wenn ich damit bezahle, kann ich Daten grundsätzlich weitergeben und dabei trotzdem eine Kopie davon behalten. Bezogen auf eine digitale Währung hieße das, dass ich mit einer digitalen Münze bezahle und zur gleichen Zeit diese digitale Münze auch an jemand Zweites geben könnte. Wenn das möglich wäre, könnte sich jeder Teilnehmer beliebig viel Geld erzeugen und die Währung hätte sehr schnell keinen Wert mehr. Organisation in Blöcken Wie aber wird verhindert, dass einmal gespeicherte Transaktionen nicht mehr verändert werden können? Dazu muss man sich die Art und Weise anschauen, wie Bitcoin die Transaktionen speichert und die der Blockchain auch ihren Namen gibt: Im Bitcoin-Netzwerk gibt es spezielle Knoten, sogenannte Mining Nodes, die Transaktionen in Blöcken zusammenfassen (Bild 2). Aufgrund der Verteilung der Knoten nimmt dabei nicht jeder Knoten die gleichen Transaktionen auf, wichtig ist nur, dass die Reihenfolge der Transaktionen ihren entsprechenden Zeitstempeln entspricht. Nur Transaktionen in abgeschlossenen Blöcken werden als unveränderlich angesehen. Solange sich eine Transaktion also nicht in einem solchen Block befindet, gilt sie nicht als ausgeführt. Damit der Mining Node nun einen Block abschließen und die Transaktionen darin als unveränderlich in das Netzwerk kommunizieren kann, muss er ein kryptografisches Rätsel lösen. Dazu muss der Hash-Wert aller Transaktionen in einem Block um einen weiteren Wert ergänzt werden, sodass der Hash-Wert des Gesamtblocks inklusive des gefundenen Werts innerhalb einer im Protokoll definierten Grenze liegt. Aufgrund der Eigenschaften von Hash-Funktionen (siehe Kasten Hash-Funktionen) bleibt den Mining-Nodes dafür nichts anderes übrig, als alle möglichen Werte so lange

5 auszuprobieren, bis sie einen Wert finden, der die Vorgaben des Rätsels erfüllt. Dieser Prozess wird im Allgemeinen als Proof of Work bezeichnet und bei Bitcoin und anderen Krypto-Währungen auch als Mining. Der allgemeine Name rührt daher, dass mit dem Ergebnis nachgewiesen wird, dass man einen bestimmten Anteil an Rechenleistung erbracht hat, um das Rätsel zu lösen. Warum ist das so wichtig? Das Erzeugen gültiger Blöcke soll so teuer sein (zum Beispiel in Form von Stromverbrauch), dass es sich nicht lohnt, Blöcke mit gefälschten Transaktionen zu erzeugen. Stattdessen wird man für das Erzeugen gültiger Blöcke belohnt, indem man einen gewissen Anteil an Bitcoins für die eigene Arbeit erhält. Dazu darf man eine eigene Transaktion in den neuen Block aufnehmen, die aus dem Nichts einen vorher definierten Betrag in die eigene Wallet überträgt (deswegen Mining, weil das virtuelle Geld geschürft wird). Außerdem darf man bei Bitcoin sogenannte Transaktionsgebühren einbehalten. Warum lohnt es sich dann nicht, zu betrügen? Jeder andere Knoten hat ja eine Kopie aller Transaktionen und kann sehr leicht feststellen, ob ein Block valide Transaktionen enthält. Wenn ein Knoten betrügen möchte, müsste er gefälschte Transaktionen in einem neuen Block zusammenfassen, das rechenintensive (teure) Rätsel lösen und dann den neuen Block den anderen Knoten als abgeschlossen und gültig präsentieren. Diese nehmen aber einen neuen Block nur dann auf, wenn zum einen das Rätsel richtig gelöst wurde und zum anderen auch alle Transaktionen in dem Block valide sind. Das bedeutet, dass man zwar einen neuen gefälschten Block in das Netzwerk schicken kann, aber niemand wird diesen Block als gültig akzeptieren. Und das bedeutet auch, dass man keine neuen Bitcoins erhält, die man nutzen könnte. Kurzum: Man bleibt auf den Kosten zur Lösung des Rätsels sitzen. Organisation als Kette Jetzt kann man natürlich argumentieren, dass die Rechenleistung immer billiger wird und es sich dann doch irgendwann lohnen könnte, das Netzwerk so lange mit gefälschten Blöcken zu fluten, bis diese akzeptiert werden. Um das zu vermeiden, gibt es erst mal einen ganz trivialen Mechanismus: Das zu lösende Rätsel wird per Protokolldefinition immer schwieriger und die Belohnung pro abgeschlossenen Block immer geringer (bei Bitcoin wird alle Blöcke die Belohnung halbiert). Zusätzlich verkettet man die einzelnen Blöcke so, dass die Fälschung eines Blocks schwieriger wird, je älter er ist. Dazu wird einfach der Hash-Wert eines abgeschlossenen Blocks als erster Transaktionseintrag in den neuen Block übernommen. Wenn sich nun also der vorherige Block verändert, muss dieser einen neuen Hash-Wert erhalten und dieser muss dann wiederum im nachfolgenden Block enthalten sein. Das bedeutet, möchte man einen alten Block manipulieren, müsste man auch alle nachfolgenden Blöcke manipulieren. Dazu müsste man wiederum für den zu fälschenden sowie für sämtliche nachfolgenden Blöcke wieder das kostenintensive Rätsel lösen. Je älter also ein Block, desto unveränderlicher wird er. Daher ist es auch manchmal so, dass Transaktionen nur dann als unveränderlich beziehungsweise fälschungssicher angesehen werden, wenn diese mindestens drei Blöcke tief sind, das heißt, wenn es mindestens zwei nachfolgende Blöcke gibt, in denen der Hash-Wert durch die Verkettung ebenfalls eingeflossen ist. Vorher werden die Transaktionen in einem Schwebezustand gehalten. Im obigen Beispiel mit dem Kauf von Musik würde man also erst dann Zugriff auf das Musikstück erhalten, wenn die Transaktion mit der Zahlung in einem Block enthalten ist, auf den mindestens zwei weitere gültige Blöcke folgen. Da die Knoten im Blockchain-Netzwerk immer nur die längste Kette gültiger Blöcke (die längste Blockchain) als gültig ansehen, kann man auch nicht einfach eine neue Kette anfangen und im Netzwerk publizieren. Der gesamte Prozess ist jetzt sehr stark vereinfacht dargestellt und viele wichtige Aspekte fehlen noch, aber wer sich für die Details von Bitcoin interessiert, dem sei auf jeden Fall das Buch Mastering Bitcoin von Andreas M. Antonopoulos ans Herz gelegt [1]. Blockchain 2.0: Smart Contracts Mit Bitcoin und anderen Krypto-Währungen kann man also weltweit Geld zwischen Wallets übertragen. Im Beispiel mit den Verkehrsbetrieben könnte der eine Verkehrsbetrieb dem anderen den jeweiligen Anteil an der Monatskarte zukommen lassen. Und beim Kauf von Musik wäre die Zahlungsabwicklung ebenfalls geregelt. Das Transaktionsprinzip hinter Bitcoin wird dabei UXTO genannt und steht für Unspent Trans action Output. Das bedeutet vereinfacht gesagt, dass ich einen bestimmten Bitcoin-Betrag nur dann weitergeben kann, wenn ich vorher in einer oder mehreren Transaktionen eine ausreichende Anzahl an Bitcoins erhalten habe. Wenn man einen Betrag überweisen möchte, muss man in der Transaktion die Quell-Transaktion(en) angeben, über die man nachweisen kann, dass man über ausreichend Bitcoins verfügt. Mit jeder Transaktion werden also die vorherigen Transaktionen zu einer oder mehreren neuen Transaktion(en) verknüpft und die Blockchain repräsentiert den jeweiligen Zustand der Transaktionen; Bitcoin ist also ein Automat, der von Zustand zu Zustand überführt werden kann. Dazu gibt es auch eine einfache Skriptsprache, sodass auch komplexere Zustandsübergänge programmiert werden könnten, zum Beispiel, dass erst die Genehmigung verschiedener Personen erfolgen muss, bevor eine Transaktion durchgeführt werden kann. Diese Skriptsprache ist allerdings beschränkt und enthält beispielsweise keine Schleifen. Man hat sich also überlegt, ob man nicht die Vorteile der Blockchain mit einer Turing-vollständigen Programmiersprache kombinieren könnte, und ein Ergebnis war die Blockchain-Implementierung Ethereum und die sogenannten Smart Contracts. Das sind kurz gesagt Skripte, die einen beliebigen Sachverhalt abbilden können, auf der Blockchain abgelegt werden und daher alle bereits angesprochenen Eigenschaften haben und über eine Adresse aufgerufen werden können. Damit könnte man nun relativ einfach einen vollständigen

6 Geschäftsprozess abbilden, das heißt nicht nur die Abwicklung des Zahlungsverkehrs zwischen zwei Parteien, sondern auch die damit verbundene Gegenleistung. Im Beispiel mit dem Kauf von Musik können also Zahlung und Bereitstellung der MP3-Datei in der gleichen Transaktion erfolgen. Das bedeutet, sobald das Geld transferiert wurde, kann man auch unmittelbar auf die MP3-Datei zugreifen. Keine der beiden Parteien kann betrügen. Dazu muss natürlich die richtige Implementierung des Vertrags vorausgesetzt werden, aber da auf der Blockchain jeder eine Kopie von allem besitzen kann, kann auch jeder die Bedingungen des Smart Contracts vor der Ausführung überprüfen. Und ein einmal ausgeführter Programmcode ist unveränderlich auf der Blockchain gespeichert. Daher hört man auch manchmal Code is Law. Bei Ethereum wird der Programmcode meistens in der Hochsprache Solidity geschrieben, einer JavaScript-ähnlichen Sprache. Der Smart Contract wird dann in den Opcode für die Ethereum Virtual Machine (EVM) übersetzt, digital sig niert und auf der Blockchain gespeichert. Transaktionen, die diesen Smart Contract nutzen, rufen ihn unter einer bestimmten Adresse auf, sodass dieser von den Knoten im Ethereum-Netzwerk in der EVM ausgeführt wird. Da die Programmiersprache Turing-vollständig ist, gibt es das Problem, dass man nicht vorhersagen kann, ob und wann ein Smart Contract überhaupt vollständig ausgeführt wurde (als Halteproblem bekannt). Dieses Problem löst man, in dem jede Transaktion nicht nur die Adresse des Smart Contracts enthält, sondern auch, wie viel Gas (engl. also Sprit/Benzin) man der virtuellen Maschine mitgibt. Jede Operation kostet eine bestimmte Menge Gas, und wenn das Gas aufgebraucht ist, bevor der Smart Contract beendet ist, wird die Ausführung abgebrochen. Gas muss natürlich bezahlt werden (bei Ethereum gibt es die virtuelle Währung Ether mit dem Kürzel ETH) und hat einen Preis, den man aber pro Einheit selbst festlegen kann. Allerdings: Wählt man den Gaspreis zu gering, wird kein Knoten den Smart Contract ausführen und in den nächsten Block aufnehmen. Ethereum hat alle Eigenschaften, die schon für DLT und Blockchain genannt wurden, das heißt, im Prinzip hat man einen dezentralen Computer geschaffen, den keine Einzelperson kontrolliert, auf dem beliebige Programme ausgeführt werden können, von Teilnehmern, die sich weder kennen noch vertrauen müssen. Manche Konzepte bei Ethereum ähneln denen bei Bitcoin (Ethereum hat zum Beispiel einen etwas anderen Proof-of- Work-Algorithmus), andere sind grundlegend überarbeitet worden. Neben Bitcoin und Ethereum gibt es aber auch noch viele weitere Blockchain-Implementierungen, und der Markt unterliegt derzeit einem konstanten Wandel. Insbesondere technische Aspekte werden mit einer enormen Geschwindigkeit weiterentwickelt, sodass es sich lohnt, nah an dem Thema dranzubleiben. Microsoft und Blockchain Bei Microsoft hat man schon vor einiger Zeit angefangen, sich aktiv mit dem Thema Blockchain zu beschäftigen. Von außen hat man aber die Arbeit erst wahrgenommen, als Mitte 2016 ein Whitepaper zu Project Bletchley [2] veröffentlicht wurde. Darin wurde ein recht einfaches Problem von Blockchains beschrieben, dessen Lösung sich aber bisher als sehr schwierig herausgestellt hat: Sobald man die Blockchain verlässt und zum Beispiel Daten von außerhalb benötigt (Aktien kurse oder Ähnliches), kann die Vertrauenswürdigkeit nicht mehr sichergestellt werden. Niemand kann ohne Weiteres außerhalb der Blockchain prüfen, ob die externen Daten tatsächlich vertrauenswürdig sind. In dem Whitepaper wurde dazu ein viel beachtetes Konzept der Cryptlets vorgestellt, die es erlauben, eine vertrauenswürdige Brücke zwischen Blockchains (On-Chain) und der Außenwelt (Off-Chain) zu bauen. Hinter Project Bletchley stand aber auch eine wichtige strategische Richtung von Microsoft: Zum Zeitpunkt der Veröffentlichung des Whitepapers hatte sich bereits abgezeichnet, dass es nicht bei einer einzigen Blockchain-Implementierung bleiben würde. Entwickler werden möglicherweise von Anwendungsfall zu Anwendungsfall unterschiedliche Blockchains nutzen oder diese untereinander integrieren. Außerdem stellte sich heraus, dass viele Projekte noch Probleme im Produktivbetrieb hatten: Wenn man zum Beispiel immer einen privaten Schlüssel braucht, um Transaktionen zu autorisieren, wo bewahrt man als Unternehmen dann diesen Schlüssel auf? Welche Personengruppe darf ihn nutzen? Für welchen Anlass, und so weiter. Microsoft kündigte an, dass man sich genau dieser Aufgabe stelle, die Komplexität der Blockchain-Technologie für die Entwickler und Anwender reduzieren zu wollen. Mittlerweile findet man so zum Beispiel knapp 40 verschiedene Blockchain-Implementierungen und Werkzeuge im Microsoft Azure Marketplace, die man mit nur wenigen Mausklicks bereitstellen kann. Und im März 2017 wurde Microsoft Gründungsmitglied der Enterprise Ethereum Alliance mit dem Ziel, den Einsatz von Blockchain-Technologien zu vereinfachen. So offen wie Microsoft ist auch die.net Community, und in einem späteren Beitrag dieses Schwerpunkts wird mit Nethereum [3] ein Projekt vorgestellt, mit dem man.net und Ethereum zusammenbringen kann. [1] Andreas M. Antonopoulos, Mastering Bitcoin, O Reilly 2014, ISBN [2] Veröffentlichungen zu Project Bletchley, [3] Ethereum.NET Cross Platform Integration Library, Patrick Schidler ist Business Lead in der Cloud & Enterprise Group der Microsoft Deutschland GmbH und verantwortet unter anderem das Deutschlandgeschäft mit cloudbasierten Diensten rund um Blockchain. Zu erreichen ist er unter patschi@microsoft.com. dnpcode A1709BlockchainGrundlagen