Smart Contracts und das Oracle Problem - erklärt am Beispiel Immobilienkäufe
Smart Contracts oder distributed contracts wurden aus dem Bedürfnis heraus geschaffen, die Vertrauensfrage bei Verträgen zu lösen und zu automatisieren. Aber was ist eigentlich ein Vertrag? Abstrakt gesagt ist ein Vertrag eine Vereinbarung zwischen mindestens zwei Parteien, wobei sich diese Parteien an die Vereinbarung halten müssen. Falls einer gegen die Vereinbarung verstößt, gibt es äußere Instanzen, die die Prozedur überprüfen sowie gegebenenfalls Konsequenzen erlassen und durchführen.
Smart Contract am Beispiel Immobilienkauf
Ein konkretes Beispiel für einen Vertrag ist der Immobilienkauf: Immobilienkäufer und -verkäufer schließen einen Kaufvertrag ab. Der Käufer wird als neuer Eigentümer ins Grundbuch eingetragen, sobald der Kaufpreis und die Grunderwerbsteuer bezahlt wurden. Da ein Notar involviert ist und es diverse Vorschriften gibt, kann beispielsweise der Verkäufer die Immobilie nicht mehrfach verkaufen (double spending problem) oder der Käufer als neuer Eigentümer eingetragen werden ohne den Kaufpreis zu bezahlen. In diesem simplen Beispiel haben wir zusätzlich zu den beiden direkt involvierten Parteien - Käufer und Verkäufer - bereits mindestens drei weitere Parteien, denen wir vertrauen müssen:
- dem Notar,
- dem Grundbuchamt,
- dem Finanzamt
und im Fall von Rechtsstreitigkeiten müssten wir natürlich auch noch dem Rechtsstaatsystem vertrauen.
Smart Contracts und das Oracle
Um einen Vertrag erfolgreich durchführen zu können, müssen wir somit diversen äußeren Parteien vertrauen - den sogenannten Oracles. Mit Smart Contracts hat man nun den Wunsch diesen Prozess zu vereinfachen und die zentralisierten äußeren Parteien zu eliminieren (trustless):
- Durchführung und Durchsetzung von Verträgen wird unparteiisch und automatisch im System vollzogen
- keine zentralisierten äußeren Parteien, insbesondere ohne das Rechtssystem
Der Benutzer eines Smart Contracts muss somit niemandem vertrauen, außer dem Programmierer des Smart Contracts selbst, der hoffentlich alle Rand- und Sonderfälle in seinem Code berücksichtigt hat. Denn tatsächlich bezieht sich das 'smart' in Smart Contract nicht auf den Contract selbst, sondern auf den smarten Programmierer, der diese Regeln deterministisch in Programmcode übersetzt hat. Im Grunde genommen bedeutet somit die Verwendung von Smart Contracts nichts anderes als eine Verschiebung des Vertrauens auf andere Instanzen. In einem Smart Contract ist also der Programmcode das unumstößliche, unverhandelbare Gesetz.
Welche Rolle spielt die Blockchainplattform?
Bevor wir uns dem Oracle widmen, noch ein paar Worte zum Blockchainbetreiber. Auch den Betreibern der Blockchainplattform muss bei der Vertragsdurchführung vertraut werden. Hierbei ist der Begriff Dezentralisierung immer ein Verkaufsargument. Dezentralisierung ist jedoch ein sehr hartes Konzept:
- die Daten müssen auf jedem Node existieren, also das gesamte Netzwerk muss synchronisiert werden (scaling problem),
- das Programm, also der Smart Contract, entscheidet dabei welche Daten in diese Datenbank (Blockchain) geschrieben werden.
Wir unterscheiden hier folgendes:
- Strikte Dezentralisierung: keine einzelne Organisation, Instanz oder Gruppe von Personen kann die Blockchain wesentlich beeinflussen. Eine 50% Attacke kann man auf absehbare Zeit ausschließen. Ein Beispiel hierfür ist Bitcoin.
- Schwache Dezentralisierung: auch verteilte Systeme genannt. Hier können einzelne Organisationen, Instanzen oder eine Gruppe von Personen die Blockchain wesentlich beeinflussen. Oder eine feindliche 50% Attacke ist auf absehbare Zeit nicht auszuschließen.
Das bedeutet nun, bei einer strikt dezentralisierten Blockchain vertraut man der gesamten Community, also der Node Infrastruktur, wie z.B. bei Bitcoin. Allerdings tritt hier die Schwierigkeit auf, dass der Programmcode des Smart Contracts zu 100% fehlerfrei bei der Veröffentlichung sein muss und Bugs können nicht einfach behoben werden. Im besten Fall sind Iterationen des Programms sehr langsam. Als Investor vertraut man deshalb auf die Unfehlbarkeit der Programmierer. Der DAO Fall in Ethereum verdeutlicht diese Probleme sehr gut. Darüber hinaus wird ersichtlich, dass zu diesem Zeitpunkt Ethereum das Kriterium der strikten Dezentralisierung nicht erfüllt hat, da die Macher von Ethereum die Beträge vom DAO Fall wieder zurückrollten und Ethereum Classic dadurch entstand.
Ist die Struktur allerdings schwach dezentralisiert, so vertraut man einzelnen Organisationen oder einer Handvoll Programmierer oder hofft darauf, dass die Blockchain uninteressant genug ist für eine 50% Attacke. Was bedeutet hier Vertrauen in diesem Kontext? Nun, jemand mit wesentlichem Einfluss kann im Hintergrund zum Beispiel Transaktionen doppelt buchen (double spending) und sich dabei selbst bereichern. Oder im Fall einer kontrollierenden Organisation kann es zu Vetternwirtschaft kommen und es können z.B. befreundete Organisationen bei der Durchführung bevorzugt werden (siehe DAO Fall von oben).
Als Investor in Kryptowährungen kann man sich also die Frage stellen, welchen Zweck die Currency eigentlich erfüllen soll und ob dafür eine strikt dezentrale Struktur geeignet ist. Hat man einen Anwendungsfall, bei dem ohnehin nur eine einzige Institution wie z.B. der Staat die Blockchain kontrollieren soll, kann man sich fragen, warum auf die Komplexität der Blockchain zurückgegriffen wird. Denn dieser Fall ist ja automatisch zentralisiert (z.B. hat der Staat zentrale Kontrolle) und könnte unter Umständen einfach mit einer klassischen Lösung wie z.B. redundante Datenbank mit signierten Ein- und Ausgängen effizienter und billiger umgesetzt werden. Das Argument, dass in der Blockchain ja alles auf ewig gespeichert wird ist in so einem Fall nicht mehr gültig, da ja die einzelne Instanz (hier im Beispiel der Staat) die volle Kontrolle über die Blockchain hat und somit auch Einträge rückgängig machen oder verändern kann (siehe DAO Fall von oben).
Das Oracle Problem
Zurück zu unserem Immobilienkaufbeispiel: nehmen wir an, der Kauf wurde über einen Smart Contract abgewickelt auf einer strikt dezentralen Struktur (zur Erinnerung: keine einzelne Instanz kann die Blockchain beeinflussen und eine 50% Attacke kann man ausschließen). Woher weiß nun die digitale Welt, wie es um die Immobilie steht? Und was passiert, wenn der neue Eigentümer sein Token verbummelt? Wem gehört dann die Immobilie? Muss dann doch wieder das Rechtssystem eingeschaltet werden, das aus dem Prozess eliminiert werden sollte? Das ist das sogenannte Oracle Problem.
Das Oracle dient bei einem Smart Contract als Datengeber und als Datennehmer. Hierbei hat das Oracle immer das letzte Wort in einem Smart Contract und muss daher zu 100% vertrauenswürdig sein. Denn in einer strikt dezentralen Struktur kann kein Rechtssystem von außen eingreifen. Alle Beteiligten müssen somit das Wort des Oracles akzeptieren - egal was es sagt. Das bietet eine breite Angriffsfläche für Oracles:
- wer kontrolliert die Datenströme?
- können die Datenströme gehackt werden?
- wie groß ist der Anreiz, das Oracle direkt oder indirekt zu kompromittieren?
Nehmen wir an, der Immobilienkauf würde über einen Smart Contract abgewickelt und die Oracles wären der Notar, das Grundbuchamt und das Finanzamt. Alle drei müssten digitale Daten mit dem Smart Contract sicher und unfehlbar austauschen können. Desweiteren sollte der Smart Contract als implizierte Exekutive auch dafür sorgen, dass der alte Besitzer keinen Zugang mehr zur Immobilie besitzt und der neue Besitzer die Schlüssel bekommt. Jetzt könnte man das natürlich über Smart Homes mit smarten Türschlössern und smarter Einrichtung eventuell annähernd realisieren. In dem Moment, wo einer von diesen Datengebern (also auch das smarte Türschloss) versagt oder kompromittiert ist, funktioniert aber der komplette Vertrag nicht mehr richtig, da keine verlässlichen Daten mehr reinkommen. Das heißt im Klartext, die Oracles selbst müssen eine strikt dezentrale Struktur aufweisen, damit man verlässliche Daten bekommt.
Das zeigt schon eine grundsätzliche Schwierigkeit, Verträge über physische Güter mit Smart Contracts abzuwickeln. Ähnliche Probleme hätte man zum Beispiel auch mit über Smart Contracts gehandelten Goldbarren. Man kann diese zwar mit einer Signatur im Hologramm versehen, die einem Token zugeordnet ist. Aber auch hier müsste der Barren den Besitzer automatisch wechseln können ohne eine äußere Instanz zu involvieren. Und was passiert, wenn der Barren wieder eingeschmolzen wird? Und wer verwaltet eigentlich alle Goldbarren und stellt deren Echtheit fest?
Wie sieht es nun aus mit digitalen Gütern oder Dienstleistungen? Wenn wir z.B. Smart Contracts auf Sportwetten anwenden wollten, so müssten wir gewährleisten, dass die Sportergebnisse zuverlässig in der Blockchain ankommen. Die Oracles sind in diesem Fall somit diejenigen, die die Sportergebnisse festhalten und digitalisieren. Das müsste allerdings dann in einem strikt dezentralen Kontext stattfinden, was kaum zu realisieren ist. Und wenn strikte Dezentralisierung für Oracles nicht realisierbar ist, stellt sich sogleich die Frage, wie groß der Anreiz ist diese Daten oder Datenströme zu manipulieren.
Fazit
Während die grundsätzliche Idee von Smart Contracts durchaus verlockend scheint, so ist die zuverlässige und sichere Umsetzung eine sehr große Herausforderung. Insbesondere das Oracle Problem erweist sich als sehr große Hürde. Wenn man sich für eine Cryptocurrency mit Smart Contracts interessiert, kann man sich die folgenden Fragen stellen:
- Wie komplex ist das vertragliche Problem und wie ist der Zusammenhang zu geltenden Gesetzen?
- Benötigt die Lösung eine strikt dezentrale Struktur und wenn ja, ist diese auch gewährleistet?
- Wie sicher und zuverlässig sind die Oracles in diesem System? Sind sie strikt dezentralisiert?
Aufgrund der Komplexität und des Oracle Problems können wir kaum erwarten, dass Immobilienkäufe in absehbarer Zukunft über Smart Contracts abgewickelt werden. Und wenn dies doch geschieht, dann wird es wahrscheinlich eine Mischlösung sein, die vermutlich ohne Blockchain viel effizienter und skalierbarer umgesetzt werden könnte.
Dieser Artikel ist auszugsweise in der Geldmag Ausgabe im April 2021 zum Thema Kryptowährungen erschienen.
Empfehlenswerte Finanzblogs, die auch für das Geldmag geschrieben haben
Insgesamt haben 18 Finanzblogger über Kryptowährungen in der dritten Geldmag Ausgabe geschrieben. Unter anderem sind folgende empfehlenswerte Finanzblogger dabei (Liste im Aufbau):
- gut-veranlagt.de - Kryptowährungen handeln in einer Stunde?
- finanzpla.net - Krypto-Mining: Was Mining bedeutet, wie es funktioniert und wie man selbst davon profitiert
- hauskauf-blog.de - 3 Gründe, weshalb die starke Kursentwicklung von Bitcoin keine Spekulationsblase ist
- phinanzielle-freiheit.at - Kryptowährungen und Steuern
Verlieren Sie auch manchmal den Überblick?
