Woher weiß ein Smart Contract, dass es in London geregnet hat?

Stell dir einen Smart Contract mit einer sehr einfachen Regel vor:

Wenn es in Innenstadt-London heute mindestens 10 Millimeter regnet, zahle Alice 10.000 Dollar aus.

Das Geld ist bereits hinterlegt. Die Bedingung steht im Code. Niemand muss den Anspruch genehmigen oder über die Auszahlung verhandeln.

Es gibt nur eine unangenehme Frage.

Woher weiß der Contract, dass es geregnet hat?

Er kann nicht aus dem Fenster schauen. Er kann nicht zu einer Wetterstation gehen. Und während der normalen Ethereum-Ausführung kann er nicht einfach eine Webverbindung öffnen und eine Wetter-API fragen, was passiert ist.

Das Erstaunliche ist, dass diese Blindheit kein fehlendes Feature ist. Sie ist Teil dessen, was das System überhaupt funktionieren lässt.

Die blinde Maschine

Ethereum ist nicht ein einzelner Computer, der deinen Contract ausführt. Viele unabhängige Nodes müssen dieselben Transaktionen verarbeiten und zum selben Ergebnis gelangen. Ausgehend vom selben vorherigen Zustand und denselben Transaktionseingaben müssen sie genau denselben neuen Zustand berechnen ^[1].

Stell dir nun vor, der Contract könnte mitten in der Ausführung eine normale Web-API aufrufen.

Ein Node fragt um 14:03:01 Uhr an und erhält 9,9 mm. Ein anderer fragt eine Sekunde später an und erhält nach einem Datenbank-Update 10,1 mm. Ein dritter erleidet einen Netzwerk-Timeout.

Plötzlich haben identische Blockchain-Transaktionen keine identischen Eingaben mehr.

Deshalb verhalten sich Smart Contracts nicht wie gewöhnliche Webanwendungen. Die Ethereum Virtual Machine (EVM) ist während der Ausführung bewusst von beliebigen Netzwerkanfragen isoliert. Externe Informationen müssen in einer Form in die Blockchain gelangen, die jeder Node sehen und der jeder zustimmen kann.

So kann Ethereum extrem sicher sein bezüglich der Dinge, die sich bereits in seiner eigenen Welt befinden — Kontostände, Signaturen, Contract-Speicher, Token-Transfers —, während es von sich aus absolut nichts über den Regen draußen weiß.

Jemand muss die Tatsache hineinbringen

Hier kommen Orakel (Oracles) ins Spiel ^[1].

Im einfachsten Fall könnte ein Off-Chain-System eine Wetterquelle auslesen, einen Wert wie 12,4 mm signieren und diesen Wert an einen Contract übermitteln. Anspruchsvollere Orakelsysteme können viele Reporter, Datenquellen, Signaturen, Marktbeobachtungen oder Einspruchsmechanismen kombinieren.

Aber das grundlegende Problem bleibt immer dasselbe: Etwas außerhalb der Blockchain muss zu einer Information werden, die die Blockchain nutzen kann.

Angenommen, eine autorisierte Orakel-Adresse übermittelt:

Regenmenge in London heute: 12,4 mm.

Ethereum kann die digitale Signatur verifizieren. Es kann beweisen, welcher Schlüssel die Nachricht autorisiert hat. Es kann genau beweisen, welcher Wert übermittelt wurde und wann er in die Chain gelangt ist.

Was es aus der Signatur allein nicht beweisen kann, ist, dass tatsächlich 12,4 mm Regen gefallen sind.

Dieser Unterschied ist das Herzstück des Orakel-Problems:

Das Verifizieren einer Nachricht ist nicht dasselbe wie das Verifizieren der Realität.

Hacke das, woran der Contract glaubt

Das ist von enormer Bedeutung, denn Smart Contracts brauchen keinen Bug im Code, um ein katastrophales Ergebnis zu erzeugen. Manchmal tut der Code genau das, wofür er entworfen wurde — mit einer falschen Eingabe.

Ein Kreditprotokoll ist ein gutes Beispiel. Stell dir vor, du hinterlegst Sicherheiten im Wert von 150 Dollar, um 100 Dollar zu leihen. Der Contract muss ständig prüfen, was diese Sicherheit wert ist. Fällt ihr Wert zu tief, kann die Position liquidiert werden.

Alles hängt vom Preis ab.

Im Oktober 2021 verlor C.R.E.A.M. Finance rund 130 Millionen Dollar durch einen Angriff auf seinen Kollateral-Bewertungsmechanismus ^[2]. Der Angreifer nutzte riesige Mengen vorübergehend geliehenen Kapitals und manipulierte einen Wert, der für die Bewertung von yUSD-Vault-Sicherheiten verwendet wurde.

Das wichtige Detail ist nicht die Komplexität der Trades. Es ist das, was als Nächstes passierte.

Das Kreditsystem akzeptierte einen aufgeblähten Kollateralwert und verhielt sich entsprechend. Aus der Sicht des Contracts schien der Angreifer viel wertvollere Sicherheiten zu besitzen, als ökonomisch gerechtfertigt war, sodass das Protokoll riesige Kredite in anderen Assets zuließ.

Der Contract hatte nicht vergessen, wie Überbesicherung funktioniert.

Er glaubte der Zahl, die ihm genannt worden war.

Blitzkredite (Flash Loans) können solche Angriffe viel mächtiger machen, weil sie einem Angreifer erlauben, riesiges Kapital innerhalb einer einzigen atomaren Transaktion zu steuern. Aber der Flash Loan ist nicht die Orakel-Schwachstelle an sich. Die tiefere Schwelle ist, dass das Protokoll einen Preis oder Buchwert akzeptiert, der günstig genug manipuliert werden kann.

Wie macht man eine Tatsache glaubwürdig?

Es gibt nicht das eine Orakel-Design, weil es nicht die eine Art externer Wahrheit gibt.

Ein sich ständig ändernder ETH-Preis ist nicht dasselbe Problem wie eine Gesamtregenmenge. Ein Marktpreis, der sich bereits On-Chain bildet, ist nicht dasselbe wie ein Flugausfall. Und ein Anspruch, der sechs Stunden auf einen Einspruch warten kann, unterscheidet sich stark von einer Liquidation, die sofort einen Preis braucht.

Verschiedene Systeme erzeugen daher akzeptable Beweise auf unterschiedliche Weise.

Frage viele Boten — Chainlink

Anstatt einem einzelnen Reporter zu vertrauen, kann ein dezentrales Orakel-Netzwerk Berichte von mehreren unabhängigen Node-Betreibern und mehreren Datenquellen kombinieren.

Chainlinks Offchain Reporting Architecture erlaubt es Orakel-Nodes, Beobachtungen Off-Chain auszutauschen und zu aggregieren und dann einen quorum-gestützten Bericht On-Chain zu übermitteln ^[3].

Die Idee ist simpel: Ein schlechter Server, eine defekte API oder ein unehrlicher Reporter soll nicht allein über die Antwort entscheiden dürfen.

Das macht die Daten nicht magisch wahr. Es verändert die Aufgabe des Angreifers. Das Bestechen einer einzelnen Quelle ist viel einfacher als das Bestechen ausreichend vieler unabhängiger Teile des Berichtssystems, um einen falschen Wert legitim aussehen zu lassen.

Beobachte den Markt selbst — Uniswap TWAP

Manchmal braucht die Blockchain gar keinen externen Boten.

Uniswap v2 und v3 können zeitgewichtete Durchschnittspreise (TWAPs) unterstützen, die aus Preisbeobachtungen abgeleitet werden, die durch bereits On-Chain stattfindende Handelsaktivitäten entstehen ^[4].

Anstatt zu fragen: „Was ist ETH genau jetzt wert?“, kann ein Protokoll etwas fragen wie:

„Welchen Preis hat dieser Markt über die letzten Minuten gezeigt?“

Das ist wichtig, denn das kurze Verzerren eines dünnen Marktes auf einen absurden Preis mag möglich sein. Das Halten dieser Verzerrung über ein längeres Beobachtungsfenster ist jedoch meist viel teurer und setzt den Angreifer Arbitrage- und Kapitalkosten aus.

Ein TWAP eliminiert Manipulation nicht. Er macht den Angriff abhängig von Liquidität, Zeit, Marktstruktur und der Art und Weise, wie das integrierende Protokoll das Ergebnis nutzt.

Bringe frische Beweise nur dann, wenn du sie brauchst — Pyth

Eine weitere Frage ist nicht, wer den Preis erzeugt hat, sondern wann die Blockchain dafür bezahlen sollte, ihn zu empfangen.

Manche Orakelsysteme pushen Updates kontinuierlich On-Chain. Das hält Daten bereit, kostet aber ständig Gas, egal ob jemand den Wert nutzt oder nicht.

Pyth ist nützlich, weil es auch ein Pull-Muster unterstützt ^[5]. Frische signierte Preis-Updates können Off-Chain existieren, bis eine Anwendung eines benötigt. Ein Nutzer oder eine Anwendung bringt dieses Update dann in die Transaktion ein, und der Contract verifiziert es vor der Nutzung.

Anstatt jeden möglichen Preis ständig zu aktualisieren, kann die Anwendung effektiv sagen:

„Ich brauche jetzt einen frischen Preis. Hier ist der signierte Beweis.“

Pyth unterstützt auch Push-Integrationen, die echte Unterscheidung ist also architekturell: Sollen Daten kontinuierlich On-Chain leben oder erst ankommen, wenn die Ausführung sie tatsächlich braucht?

Nimm an, dass es wahr ist, bis jemand widerspricht — UMA

Und dann gibt es den wunderbar anderen Ansatz: Versuche nicht, jeden Anspruch im Voraus zu beweisen.

UMAs Optimistisches Orakel erlaubt es jemandem, eine Antwort vorzuschlagen und mit ökonomischem Wert zu hinterlegen. Ein Einspruchsfenster folgt. Wenn niemand den Anspruch anficht, kann das System ihn akzeptieren. Wenn ihn jemand anficht, eskaliert die Frage in UMAs Streitbeilegungsverfahren ^[6].

Das macht Sinn für Tatsachen, die keine Millisekunden-Updates brauchen und schwer als permanenter Preisfeed zu kodieren wären.

Die Logik ist fast sozial:

Wir akzeptieren diesen Anspruch, es sei denn, jemand ist bereit, Geld zu riskieren und zu sagen, dass er falsch ist.

Die meiste Orakel-Sicherheit geht darum, die Kosten einer Lüge zu verändern

Blicke über diese Designs und ein Muster wird sichtbar.

Keines von ihnen öffnet ein magisches Fenster, durch das die Blockchain die Realität direkt betrachten kann.

Stattdessen machen sie falsche Informationen schwerer, langsamer, riskanter oder teurer in der Akzeptanz.

Ein dezentraler Feed erfordert möglicherweise das Bestechen mehrerer unabhängiger Reporter. Ein TWAP kann einen Angreifer zwingen, einen verzerrten Markt über Zeit zu halten. Ein optimistisches Orakel kann einen falschen Anspruch anfällig für Einsprüche und den Verlust der Kaution machen.

Kryptografische Signaturen fügen eine weitere Schicht hinzu: Sie können es extrem schwer machen zu fälschen, wer was gesagt hat.

Das Ingenieurproblem ist daher meistens nicht:

Wie machen wir Lügen unmöglich?

Sondern:

Wie machen wir eine akzeptierte Lüge teurer in der Erzeugung, als sie an Gewinn einbringt?

Selbst perfekte Kryptografie braucht immer noch ein Fenster

Hier wird das Problem noch merkwürdiger.

Moderne Kryptografie kann bemerkenswerte Dinge beweisen. Ein Beweis kann belegen, dass eine Berechnung korrekt ausgeführt wurde, dass ein bestimmter Schlüssel Daten signiert hat, dass ein Wert in einem authentifizierten Datensatz enthalten war oder dass eine private Eingabe eine öffentliche Bedingung erfüllt.

Aber nimm an, ein Regensensor signiert:

Regenmenge: 10,2 mm.

Kryptografie kann beweisen, dass der Schlüssel des Sensors diese Nachricht wirklich signiert hat und dass sie danach niemand verändert hat.

Sie kann dir immer noch nicht sagen, ob der Sensor richtig kalibriert war, ob jemand Wasser darüber gegossen hat oder ob er sich tatsächlich in London befand.

Ein Beweis kann das digitale Beweisstück außerordentlich vertrauenswürdig machen.

Irgendeine Beobachtung muss diesen Beweis aber immer noch mit der Welt verbinden.

Der Contract kann immer noch nicht nach draußen schauen

Das ist der Teil, der hinter Phrasen wie Code is Law verborgen bleibt.

Ein Smart Contract kann die Konsequenzen einer akzeptierten Tatsache unnachgiebig machen. Sobald das System 12,4 mm Regen akzeptiert, kann die Auszahlung automatisch, deterministisch und kaum noch aufzuhalten sein.

Aber der Code erzeugt die Tatsache nicht.

Jemand hat etwas gemessen. Ein Markt hat einen Preis erzeugt. Reporter haben Beobachtungen signiert. Trader haben einen Durchschnitt gebildet. Ein Proposer hat einen Anspruch gepostet und niemand hat widersprochen.

Das Orakel ist die Maschinerie, die einen dieser Prozesse in etwas verwandelt, worauf die Blockchain bereit ist zu handeln.

Und das bedeutet, dass die tiefste Orakel-Frage nicht wirklich lautet:

Wie bekommt Blockchain-Code externe Daten?

Sondern:

Warum sollte die Blockchain ihnen glauben?

Der Contract kann beweisen, wer die Zahl gesendet hat.

Er kann immer noch nicht nach draußen schauen und sehen, ob es regnet.