IT PRAXIS IN DER FINANZWIRTSCHAFT31. Oktober 2018

Frontrunning auf der Ethereum-Blockchain verhindern – so funktioniert es in der Praxis

Paul Claudius ist Blockchain-Spezialist und erklärt, wie man Frontrunning verhindert
Paul Claudius, BlockstateBlockstate

Frontrunning ist ein altbekanntes Problem, bei dem Informations­vorteile monetär profitabel umgesetzt werden können. Eine Lösung für dieses Problem bieten die Blockchain-Technologien, die für Transaktionen genutzt werden können und um Orders mit einem revisionssicheren Audit-Trail abzuwickeln. Doch wie funktioniert das konkret?

von Paul Claudius, Blockstate

Die grundlegende Idee ist dabei, eine später nicht mehr revidierbare Absichtserklärung zum Kauf oder Verkauf von Positionen auf die Blockchain zu schreiben und diese Erklärung direkt mit dem monetären Wert der Order auszustatten. Die anschließende Order wird dann auf traditionellem Wege an einen Markt übermittelt. Der Gegenpartei wird allerdings kryptographisch bewiesen, dass diese Absichtserklärung, samt der dafür nötigen Geldmittel, vorliegt. Nach Ausführung der Order wird schließlich die Absichtserklärung veröffentlicht und findet Eingang in das revisionssichere Ledger-Log der Blockchain. Außerdem wird automatisch der vorher eingezahlte Geldwert an die Gegenpartei überwiesen.

So funktioniert das Anti-Frontrunning in der Praxis:

Eine Blockchain ist ein verteiltes Computersystem, in dem Transaktionen versendet werden können. Diese Transaktionen werden periodisch in verketteten Blöcken zusammengefasst, wodurch sie eine relative Ordnung erhalten. Dadurch können sie zu einem Transaktions-Log zusammengefasst werden. Das Erstellen eines einzelnen Blocks ist durch ein mathematisches Rätsel sehr rechenaufwändig. Alle Computer, die gleichzeitig parallel daran arbeiten, schaffen dies bei Ethereum im Schnitt als Kollektiv nur alle 15 Sekunden. Da die Blöcke aufeinander verweisen, ist es extrem teuer und aufwändig, einen älteren Block zu fälschen: Ein Angreifer müsste nämlich nicht nur den betreffenden Block fälschen, sondern auch alle darauf folgenden Blocks. Effektiv bräuchte er dafür mehr als 50% der Netzwerkrechenleistung.

Transaktionen gehen immer von einer Adresse an eine andere. Jeder Teilnehmer kann beliebig viele solcher Adressen erzeugen. Adressen sind öffentliche Schlüssel eines asymmetrischen Schlüsselpaars. Um Ether auszugeben, muss man beweisen, dass man auf Mittel aus einer vorherigen Transaktion zugreifen kann. Dies geschieht durch eine Signatur mit dem privaten Schlüssel der Empfängeradresse der vorherigen Transaktion.

Ethereum hat nun nicht nur „klassische“ Adressen (also Wallets von mehr oder weniger natürlichen Personen), sondern bietet auch „Smart Contracts“ an. Das sind turing-vollständige, ausführbare Transaktionen, die selbst eine Adresse besitzen. Smart Contracts können dementsprechend auch Geldmittel empfangen und versenden.

Tokens – von Smart Contracts verwaltete Währungseinheiten

In der Ethereum-Community hat sich ein System entwickelt, das es erlaubt, eine Art eigene Währung einzuführen, die von einem Smart Contract verwaltet wird. Die Währungseinheiten in einem solchen System, denen immer eine Adresse zugeordnet ist, nennt man „Token“. Token können für unterschiedliche Kontexte genutzt werden – zum Beispiel zur Verwaltung von Wertpapierbesitz. Kauft ein Nutzer also ein Wertpapier, besitzt er nach dem Kauf einen Token mehr als zuvor. Diese Token sind standardisiert und können direkt zwischen Nutzern transferiert werden.

Aufbau des Ordersystems

Das zugrundeliegende Ordersystem besteht aus mehreren Komponenten und kann in einen bestehenden Markt integriert werden – wie das Beispiel der Wertpapierverwaltung aufzeigt.

Für das Beispiel konzentrieren wir uns der Einfachheit halber auf nur eine Klasse von Wertpapieren, die alle den gleichen Wert haben. Der Besitz eines Wertpapiers soll einem Token im dazu entworfenen Smart Contract entsprechen. Ein Nutzer, der verschleiern möchte, wie viele Wertpapiere im eigenen Besitz sind, kann die Token natürlich auf einer Vielzahl von Adressen halten, die alle erstmal keinen sichtbaren Zusammenhang haben. Im Extremfall erzeugt der Nutzer eine Adresse pro Token. In dem Fall muss er aber auch den privaten Schlüssel pro Adresse sicher speichern – verliert er den Zugriff auf den Schlüssel, kommt er auch nicht mehr an den Token.

Autor Paul Claudius, Blockstate
Paul Claudius ist Mitgründer und Managing Director von Blockstate, dem Anbieter von Blockchain-basierten Infrastrukturmodulen für die Finanzindustrie. Der Seriengründer, Finanzexperte und Kryptoinvestor war zuvor Director Europe bei der nu3 group in Berlin. Seine Karriere begann Paul Claudius bei der BNP Paribas in New York und der AXA Private Equity in Frankfurt am Main. Er hat zudem in diverse Startups im Health Tech, IoT und E-Commerce-Bereich investiert und diese beraten.

Ein Nutzer kann nun die Wertpapiere an einer klassischen Börse handeln und eine Gegenpartei finden. Diese Gegenpartei ist auch Teilnehmer am System und möchte die Wertpapiere gerne gegen eine Währungseinheit (in dem Falle Ether) tauschen. Eine solche Tauschtransaktion würde aber, bevor sie in einem Block integriert ist, mindestens einige Sekunden durch das ganze Ethereum-Netzwerk geflutet werden, damit sie überhaupt erst in die Blockchain gelangen kann. Die Miner müssen erst von der Transaktion erfahren, damit sie sie verarbeiten können. Das führt zu einer spannenden Situation für einen Beobachter, der die noch nicht bestätigte Transaktion sieht und nun aufgrund der gewonnenen Informationen über Größe, Art und Zeitpunkt der Order auf demselben Markt noch schnell eine eigene Order einfügen kann, die ihm aufgrund seines Informationsvorsprungs garantiert Gewinn bringt. Um diesem Informationsvorsprung entgegenzuwirken, wird ein sogenanntes „Commitment-Scheme“ verwendet. Hiermit bestätigen die Nutzer untereinander, dass sie ehrlich handeln, aber keine externe Partei erfährt davon, bis die Transaktion nicht schon unter Dach und Fach ist.

Commitment-Phase – kanalübergreifende Absicherung

Angenommen Alice möchte ein Wertpapier bei Bob zum Preis von einem Ether kaufen. Anstatt nun in dem Token-Smart-Contract die Transferfunktion aufzurufen und gleichzeitig einen Ether zu überweisen, kontaktiert Alice Bob aber über einen anderen Kanal – egal, ob in Form einer klassischen E-Mail bis hin zu einer automatisierten REST-API. Wichtig ist hierbei nur, dass es sich um eine Punkt-zu-Punkt-Kommunikation handelt.

Dort fordert sie die Übertragung des einen Wertpapiers an. Damit Bob aber nicht nur das Versprechen von Alice hat, ihm auch ganz bestimmt später den einen Ether zu überweisen, schickt Alice außerdem ein Commitment mit. Dieses Commitment ist ein Hash über die Transaktionsparameter (Preis, Art des Wertpapiers, etc.) sowie eine Adresse auf der Blockchain, auf die Alice bereits einen Ether überwiesen hat. Diese Adresse kann Bob überprüfen und bei Vorhandensein des Ethers kann er Alice das ihr zustehende Wertpapier übertragen.

Reveal-Phase: Woher kommt die Adresse auf der Chain?

Nach dem Erhalt der Wertpapiere besteht für Alice der nächste Schritt darin, den noch ausstehenden Ether an Bob zu übertragen. Doch dieser liegt „gesperrt“ auf einer mehr oder weniger zufälligen Adresse in der Blockchain – Alice besitzt den privaten Schlüssel für diese Adresse nicht. Dazu erzeugt Alice nun einen speziellen Smart Contract. Dieser ist sehr einfach gehalten: Der Contract prüft, welche Menge an Ether auf seiner Adresse liegen und leitet diese an eine vordefinierte Empfängeradresse weiter. Der Smart Contract wird dafür mit einer speziellen Instruktion CREATE2 in der Ethereum Virtual Machine erstellt, die es erlaubt, den erstellten Smart Contract an eine vorberechenbare Adresse auszurollen. Der Empfänger der Ether kann also nach Sichtung der Summe diese an sich selbst weiterleiten, wenn der Absender seine Adresse als Ziel definiert hat. Dass er das auch getan hat, stellt der Empfänger über den mitgeteilten Hash sicher, der auch vom Quellcode des Smart Contracts abhängt.

Der beispielhafte Quellcode für einen solchen Weiterleitungs-Smart-Contract ist weiter unten abgebildet. Die Adresse „target“ ist das Ziel der Ether, der Konstruktor wird beim Erstellen des Contracts aufgerufen und überprüft, dass auch nur der designierte Empfänger diesen Weiterleitungs-Contract aufrufen kann. Im Falle unseres Beispiels würde Bob diesen Smart Contract ausrollen, so dass er sicher sein kann, die geblockten Ether zu erhalten. Dass der Contract auch dort ankommt, stellt er durch das Erstellen mittels CREATE2 sicher. Die Adresse des Contracts lässt sich nämlich durch einen Hash über den Quellcode und die Adresse des Erstellers vorher berechnen.

Weiterleitungs-Smart-Contract für die Ether aus der Commit-Phase

Sicherheitsanalyse – Schutz vor Betrug

Die vorgestellte Smart-Contract-Lösung stellt für alle Beteiligten sicher, dass kein Teilnehmer den anderen betrügen kann. Der Absender der Funds kann darauf vertrauen, dass der Empfänger die Wertpapiere übermittelt. Der Zugriff auf die geblockten Ether muss erst überreicht werden, wenn die Wertpapiere eingetroffen sind. Vorher wird (als Beweis des Commitments) lediglich der Hashwert des Commits übermittelt, so dass der Empfänger sicherstellen kann, dass ein valides Commitment vorliegt.

Der Empfänger wiederum kann nach Übersenden der Wertpapiere sicher sein, die geblockten Ether auch zu erhalten, da diese nur für ihn wiederherstellbar auf der Blockchain liegen. Durch die Ablage an der Adresse, die entsteht, wenn der Forwarder-Contract für den Empfänger ausgerollt wird, kann kein anderer (auch nicht der Absender) diese Ether wiederherstellen. Der Absender hat also das Geld schon aus seiner Kontrolle abgegeben und damit keinen Anreiz mehr, sich nicht dem Protokoll entsprechend zu verhalten.

Dadurch haben beide Parteien die Sicherheit von der jeweils anderen nicht betrogen zu werden. Selbst wenn das Protokoll nicht entsprechend der Abmachung befolgt wird, kann keine der Partei einen finanziellen Vorteil erlangen.

Privatsphärenanalyse

Beide Parteien können dabei vollständig anonym voneinander agieren. Auch der Wertpapierhandel muss technisch nicht zwingend so erfolgen, dass die beiden ihre echten Identitäten kennen. Es reicht aus, einen sicheren Kanal zur Kommunikation zu verwenden und die (anonymen, weil frischen) Adressen auszutauschen. Auch die späteren Phasen führen nicht zu einer gegenseitigen Deanonymisierung, wenn die Adressen nicht mehrfach verwendet werden.

Ausblick – Vertrauensaufbau in anonymen Systemen

Diese Art von Commitment-Systemen ist durch ihre spieltheoretische Konstruktion (keiner gewinnt bei Fehlverhalten) eine verheißungsvolle Möglichkeit, um in anonymen Systemen, in denen man sich nicht auf bereits bestehende Vertrauensverhältnisse berufen kann, sicheren Handel zu garantieren und Vertrauen aufzubauen. Das konkret vorgestellte Modell mag hauptsächlich in Finanzapplikationen eine Rolle spielen, generell ist aber auch ein weiter gefasster Einsatzzweck in Blockchains denkbar. Jedes Mal wenn die Absicherung einer externen Transaktion (auch bei nicht-monetären Daten) notwendig ist, bietet sich das vorgestellte System als mögliche Lösung an.aj

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert