Das Orakelproblem lösen

Verlässliche Blockchain-Anwendungen: Lösungen für das Orakelproblem

Samuel Brack

© Shutterstock / Kzenon

Blockchain-basierte Anwendungen sind seit einigen Jahren in aller Munde. Dabei ist es immer sehr leicht, von der „dezentralen Revolution“ zu sprechen, und das Management hat bestimmt schon viele tolle Ideen, wie man das eigene Produkt mit einer dezentralisierten App (DApp) verbessern kann. Dass aber auch handfeste technische Probleme auf dem Weg liegen können, fällt nicht unbedingt auf den ersten Blick auf. Dieser Artikel führt deshalb in das „Orakelproblem“ ein, bei dem es um den simpel erscheinenden Prozess der Eingabe in Blockchain-Anwendungen geht.

Eine Blockchain ist im Grunde genommen ein Werkzeug zur Erzeugung eines globalen Konsens über eine (geordnete) Reihenfolge von Transaktionen. Allen Blockchains gemein ist, dass dieser Konsens durch möglichst viele Teilnehmer eines Peer-to-Peer-Netzes gebildet wird und von allen Teilnehmern unabhängig verifiziert werden kann. Dafür gibt es Miner, die die Transaktionen empfangen und in Konkurrenz zueinander zu Blöcken zusammenfassen. Dabei lösen sie außerdem eine kryptografische Aufgabe, deren Schwierigkeit dafür sorgt, dass zur Erstellung eines Blocks im Durchschnitt eine bestimmte, vom Netzwerk vorgegebene Zeit vergeht, bei Ethereum zum Beispiel ca. 15 Sekunden. Diese Blöcke bilden dann eine Kette (die Blockchain), deren kryptografischer Zusammenhang nur mit sehr viel Rechenaufwand nachträglich gefälscht werden kann. Im Allgemeinen handelt es sich also um eine revisionssichere Transaktionsliste, die von normalen Angreifern nicht verändert werden kann.

Smart Contracts sind eine Erweiterung dieser Grundidee. Erstmals im System Ethereum großflächig eingesetzt, sind es quasi kleine Programme in jeder Transaktion. Diese werden parallel von allen beteiligten Minern ausgeführt, das Ergebnis landet für immer in der Blockchain. Dabei können solche Contracts mit besonderen Funktionen auch auf den monetären Wert der Transaktion zugreifen und ihn sogar verwalten. Man könnte Smart Contracts also auch als eine Art programmierbares Geld bezeichnen. Es ist jetzt schon absehbar, dass viele Bereiche der Finanzwelt durch Smart Contracts ergänzt bzw. deren Ausführung weiter automatisiert werden kann.

Eine Herausforderung ist es, diese Smart Contracts mit Daten aus der echten Welt zu füttern. Stellen wir uns ein Szenario vor: Der Ersteller des Contract möchte einer Variable den aktuellen Wechselkurs des Euro zum Dollar zuweisen. In einem normalen Programm auf seinem PC würde er das API der Europäischen Zentralbank aufrufen, um diesen Wert über das Internet zu erhalten. Im Fall eines Smart Contract weiß er aber weder, welcher Rechner am Ende diese Transaktion erfolgreich zur Blockchain hinzufügt (es gibt tausende Miner, die alle in Konkurrenz zueinander stehen, als erste das kryptografische Rätsel zu lösen und die Transaktion in die Blockchain zu integrieren), noch weiß er, welche Sicht auf die Welt dieser Rechner haben wird. Wer garantiert denn, dass dieser Rechner nicht hinter der Great Firewall of China steht und zwar Zugriff auf das Ethereum-Netzwerk hat, aber die Seite der EZB gesperrt ist?

Blockchain Whitepaper 2018

Free: Blockchain Technology Whitepaper

If building a blockchain from scratch is beyond your current scope, the blockchain technology whitepaper is worth a look. Experts from the field share their know-how, tips and tricks, development advice, and strategy for becoming a blockchain master.

 

Software Architecture Summit 2019
Stephan Pirnbaum

Lasst uns einen Monolithen (z)erlegen

mit Stephan Pirnbaum (buschmais GbR)

Scott Davis

Making Your Mobile Web App Talk

mit Scott Davis (ThoughtWorks)

Aus diesen Gründen ist es in Ethereum gar nicht vorgesehen, Daten über externe Schnittstellen der ausführenden Rechner zu besorgen. Alle Eingabedaten müssen immer selbst über eine Transaktion den Miner erreichen, um bei einer Berechnung berücksichtigt zu werden. Diese Schnittstelle zwischen Echtweltdaten und einem Smart Contract nennt man Orakel.

Ein solches Orakel besteht üblicherweise aus einer Funktion in einem größeren Smart Contract, die durch eine Transaktion aufgerufen wird und eine Variable im internen Zustand des Contract schreiben kann. Soll nun die Variable aktualisiert werden, erzeugt der Informationsgeber eine Ethereum-Transaktion mit einem Aufruf an diese Funktion mit dem gewünschten Wert als Parameter. Diese Transaktion wird an das Netzwerk verschickt und landet bei allen Minern, die diese wiederum in die globale Historie einarbeiten und sie ausführen. Das bedeutet in dem Fall, dass in der Ethereum State Machine die Funktion im Smart Contract aufgerufen wird, die wiederum die zu manipulierende Variable auf den neuen Wert setzt.

Nachdem diese Orakeltransaktion final in einem Block gelandet ist, wird der nächste Lesezugriff auf die Variable den neuen Wert ausweisen. Alle Transaktionen (und Funktionsaufrufe) in Ethereum passieren atomar. Trotz der extrem verteilten Berechnung von Smart Contracts gibt es beim Lesen einer Variable also keinen ungültigen Zustand, der lediglich das halbe Update beinhaltet.

Problemstellung im Finanzbereich

Smart Contracts sind aufgrund ihrer Verknüpfung von monetären Transaktionen und Turing-vollständigen Programmen für Anwendungen in der Finanzbranche und im Investmentbanking prädestiniert. Die dabei notwendigen Daten aus anderen Systemen, Webschnittstellen und Nutzereingaben müssen dabei selbst in Transaktionen verpackt und dem auszuführenden Smart Contract übergeben werden. Das ist jedoch nicht ganz billig: Das Ethereum-Netzwerk erzeugt Transaktionskosten beim Absender einer Transaktion, die von der Auslastung des Netzwerks abhängen. Dabei wird eine Art Auktionsverfahren benutzt. Jede Transaktion verbraucht eine bestimmte Menge Gas, abhängig vom kompilierten Maschinencode der Transaktion.

Das Gas soll die Kosten des Miners decken, der den Code schließlich ausführen muss. Eine Schleife benötigt mehr Gas als eine einfache Anweisung. Für dieses (deterministisch aus dem Quellcode berechenbare) Gas legt dann der Absender einer Transaktion einen Preis pro Gas-Einheit fest, und die Miner suchen für den nächsten Block dann die für sie profitabelsten Transaktionen aus. So kann ein Absender einer Transaktion ziemlich akkurat bestimmen, wie schnell die Transaktion in einem Block landet: Legt man einen niedrigen Preis fest, erfolgt die Inklusion der Transaktion in einen Block später, wenn im Netzwerk weniger Transaktionen unterwegs sind. Eine Garantie, dass eine Transaktion nicht verhungert, weil sie ewig auf die Aufnahme in einen Block wartet, gibt es nicht.

Diese Kosten können von wenigen Cent bis hin zu einigen Euro pro Transaktion reichen. So gab es Ende 2017 ein populäres Spiel namens Cryptokitties als Smart Contract. Allein durch die Popularität dieses einen Spiels erhöhten sich die Transaktionskosten in einem kurzen Zeitraum enorm.

Dieses Kostenargument führt zu der Idee, Kosten durch gemeinsam genutzte Daten zu sparen. So muss nicht jeder selbst die Daten eines API als Orakel verpacken, nur weil der Wechselkurs zwischen Euro und US-Dollar benötigt wird, sondern ein gemeinsam genutztes Orakel stellt diesen Kurs regelmäßig bereit und jeder Interessent kann dann programmatisch darauf zugreifen. Der exemplarische Quellcode eines sehr einfachen Orakels für den Wechselkurs zwischen Euro und dem US-Dollar ist in Listing 1 zu finden. Das Orakel ist an eine echte, von BlockState produktiv eingesetzte Software angelehnt. Die Programmiersprache für Smart Contracts ist Solidity. Das Orakel hält im Wesentlichen drei Variablen: den eigentlichen Wert, der gespeichert werden soll (der Wechselkurs), den Unix-Timestamp des letzten Updates und die Adresse desjenigen, der dieses Orakel aktualisieren darf. Das Beispiel ist bewusst sehr einfach gehalten, im Allgemeinen sind diese Contracts natürlich, wie traditionelle objektorientierte Programme auch, deutlich komplexer.

contract EURUSDOracle {
  uint256 public exchangeValue;
  uint256 public lastUpdateTimestamp;
  address owner;

  event oracleUpdated(
    uint256 exchangeValue,
    uint256 timestamp
  );

  constructor() public {
    lastUpdateTimestamp = 0;
    owner = msg.sender;
  }

  function updateOracle(uint256 newExchangeValue, uint256 newTimestamp) public {
    require(msg.sender == owner);
    exchangeValue = newExchangeValue;
    lastUpdateTimestamp = newTimestamp;
    emit oracleUpdated(newExchangeValue, newTimestamp);
  }

  function getExchangeValue() public view returns (uint256, uint256) {
    return (exchangeValue, lastUpdateTimestamp);
  }
}

Neben den drei Variablen existiert ein sogenanntes Event. Es kann aus einer Smart-Contract-Funktion aufgerufen werden und erzeugt dann ein Ereignis, das von einem Stück Frontend-Code überwacht werden kann. Übliche Frontends sind JavaScript-Applikationen, die eine Ethereum-Integration bieten. Dieses Event kann dann genutzt werden, um weitere Aktionen außerhalb des Smart Contract auszulösen.

Der Konstruktor ist hauptsächlich dazu da, den Besitzer (Owner) festzulegen, der später als Einziger Updates vornehmen darf. Der üblicherweise vorhandene Code zum Wechseln des Besitzers wurde aus Gründen der Übersichtlichkeit weggelassen.

Die letzten beiden Funktionen sind schließlich die eigentlichen Orakelfunktionen: Die erste dient dem Besitzer dazu, das Orakel mit frischen Daten zu aktualisieren. Der Funktionsaufruf geschieht über eine normale Ethereum-Transaktion, bei der das Application Binary Interface (ABI) des Smart Contract und die Parameter der Funktion mitgegeben werden. Ein Miner kann dies dann in seiner Ethereum Virtual Machine ausführen und das Ergebnis wieder in die Blockchain schreiben. Danach hält der Smart Contract den neuen Wert in den Variablen vor.

Die letzte Funktion ist von jedermann benutzbar und benötigt auch kein Gas, da sie ausschließlich den letzten Wert des Orakels lesend verarbeitet. Damit kann ein Knoten, der den aktuellen Zustand der Blockchain mitliest, lokal automatisch diesen Wert lesen und auch in einem eigenen Smart Contract verwenden.

Dieses Template ist durch seine Einfachheit gut anpassbar und flexibel für alle möglichen Anwendungen nutzbar. Die Integration in andere Smart Contracts macht es interessant, um als eine Art Baustein in einem größeren Kontext eingesetzt zu werden.

Zuverlässigkeit der Eingabedaten

Wie bereits angedeutet, muss das Update der Werte bei einem Orakel normalerweise von einer vertrauenswürdigen Instanz kommen. Da kommt der Communityansatz ins Spiel, bei dem ein Stellvertreter bestimmt wird, der die Daten einliefert. Ein weiterer Vorteil solcher von der Community geteilter Orakel ist die Zuverlässigkeit der Daten. Im Fall des Wechselkurses zwischen Euro und Dollar mag es wenig Interpretationsspielraum geben, aber was ist zum Beispiel mit dem Preis von Bitcoin? Dieser wird an verschiedenen Börsen weltweit unterschiedlich bestimmt. Es ist üblich, dann aus diesen Preisen einen Durchschnitt zu berechnen. Ein einzelner Smart-Contract-Nutzer mag gar nicht gewillt oder in der Lage sein, für alle benötigten Daten zuerst einen zuverlässigen Sammeldienst zu erstellen. Bestehende Aggregatordienste in diesem Sektor fallen immer wieder durch Inkonsistenzen und mangelnde Dokumentation auf. Ein solches gemeinsam betriebenes Orakel benötigt also erst einmal zuverlässige und genau definierte und dokumentierte Datenquellen.

Liegen diese vor, kann das Orakel diese Daten regelmäßig abrufen, in eine Transaktion packen und abschicken. Dadurch ergibt sich außerdem automatisch eine Historie, die den Preis unveränderbar in die Blockchain schreibt und für einen späteren Betrachter unmittelbar transparent werden lässt, ob das Orakel in der Vergangenheit korrekte Daten eingeliefert hat oder nicht. Aufbauend auf ein solches zuverlässiges Orakel lassen sich dann Finanzanwendungen in Smart Contracts implementieren, deren Ausführung von korrekten Daten abhängt. Die Firma BlockState entwickelt solche Anwendungen. Das darunterliegende Communityprojekt, das die Orakel mit zuverlässigen Daten wie oben angerissen bedient, heißt DIA und ist nichtkommerziell ausgerichtet.

Lösung

Wie schon angedeutet, ist die beste Lösung des Orakelproblems aus Sicht des Autors eine gemeinsam durch die Community betriebene Infrastruktur, die einerseits die Rohdaten aggregiert, vorverarbeitet und ins Orakel steckt und andererseits Kontrollmechanismen für die Community bereitstellt.

Ökonomische Anreizsysteme sind bei Kryptowährungen wegen des systemeigenen Währungscharakters besonders wirksam, und so liegt es nahe, die Datenqualität durch ein solches Anreizsystem sicherzustellen. Im Projekt DIA wird ein solches Anreizsystem umgesetzt. Open-Source-Entwickler können dort Quellcode zur Datenbeschaffung und -verarbeitung einpflegen. Mit dem im System vorhandenen Token (eine Art Währung, die nur in bestimmten Smart Contracts eine Bedeutung besitzt) kann gewissermaßen ein Einsatz bestimmt werden, mit dem man auf die Annahme oder Ablehnung eines konkreten Stücks neuen Quellcodes für eine bestimmte dokumentierte Aufgabe wettet. Nach einigen Tagen entscheidet der Smart Contract aufgrund der Wetteinsätze automatisch, ob der neue Code angenommen wird oder nicht. Auch ein Dispute-System für später entdeckte Fehler bzw. Korrekturen ist vorgesehen. Darauf basierende Finanzanwendungen, wie die von BlockState, haben dann ein solides Fundament, um zuverlässige und aktuelle Daten weiterverarbeiten zu können, zum Beispiel in einem anderen Smart Contract oder in einer Applikation, die selbst gar nicht mehr auf der Blockchain ist.

Zusammen mit Open-Source-Quellcode ergibt sich dann ein sehr transparentes System, bei dem jederzeit (auch für Daten, die schon mehrere Jahre alt sind) nachvollziehbar ist, woher diese Daten kommen, wie sie verarbeitet werden, welche Konfidenz hinter diesen Daten steht und wie sie verwendet werden. Gerade angesichts vieler undurchsichtiger Finanztransaktionen im klassischen Investmentbanking dürfte das auch insgesamt eine begrüßenswerte Entwicklung sein.

Geschrieben von
Samuel Brack
Samuel Brack
Samuel Brack ist ein Cybersecurityexperte und forscht an Datenschutz, Digitalen Währungen und Distributed Systems. Als CTOP des Goodcoin-Projekts hat er ein vollständig anonymes Bonuspunktsystem entwickelt. Samuel ist mehrfach verlegter Autor in einer Reihe von Fachpublikationen rund um IT, Sicherheit und Kryptografie. Er hält einen Master of Science in Informatik von der Humboldt Universität Berlin und ist aktives Mitglied der Berliner Hackercommunity und der IEEE Computer Society in Los Alamitos, Kalifornien. Er ist Mitbegründer der Firma BlockState, die Finanzanwendungen auf der Ethereum-Blockchain entwickelt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: