Absichtsgesteuerte Datenbereitstellung: Warum es wichtig ist und wie es funktioniert

Orakel im Kontext von Blockchains sollten Daten von außerhalb der Blockchain in die Blockchain-Welt bringen. In unserem [vorherigen Artikel] haben wir die drei verschiedenen Orakeltypen besprochen: das Pull-Orakel, das Push-Orakel und unser neues, auf Absichten basierendes Orakel.

Lassen Sie uns kurz zusammenfassen, wie sie funktionieren, damit offensichtlich wird, warum wir einen neuen Typ von Orakel, das auf Absichten basierende, benötigen.

Push-Orakel

Das „Push-Orakel“ ist wahrscheinlich die älteste Idee. Bei einem Push-Orakel sind Daten direkt auf der Blockchain verfügbar und werden nach einer bestimmten Zeit oder sobald ein Schwellenwert erreicht ist, aktualisiert. Zum Beispiel beobachtet eine Off-Chain-Komponente die durchschnittliche Temperatur in Paris. Zu Beginn beträgt sie 25 °C und dieser Datenpunkt wird auf der Blockchain vermerkt. Nun kann jeder auf der Blockchain auf diese Daten zugreifen. Es könnte eine Regel geben, dass die Daten auf der Blockchain aktualisiert werden, wenn sich die Temperatur um 1 °C ändert oder nach 60 Minuten, was als Herzschlag bezeichnet wird, um zu wissen, dass das Orakel im Allgemeinen funktioniert. Angenommen, die Temperatur steigt auf 25,6, 25,7, 25,8 °C, doch auf der Blockchain ändert sich nichts. Off-Chain wird der Trend sehr offensichtlich. Schließlich erreicht sie 26 °C und eine Transaktion wird an die Blockchain gesendet, um die Temperatur im sogenannten Orakelvertrag zu aktualisieren. 

Der wichtige Teil ist zu verstehen, was dort passiert: Die Transaktion wird gesendet, ist jedoch nicht sofort auf der Blockchain sichtbar. Sie muss zunächst geminet oder bestätigt werden. Tatsächlich ist, da alle Informationen öffentlich sind, bekannt, welcher neue Datenpunkt vor der Bestätigung der Transaktion vorliegen wird.

Angenommen, es gibt einen großen Derivatemarkt auf der Blockchain, der diese Daten nutzt, auf dem Sie auf die Temperatur wetten können. Es könnte so einfach sein: Sie wetten, dass die Temperatur steigen wird, aber Sie können Ihre Position jederzeit schließen. Wenn Sie jemals Optionen gehandelt haben, könnte Ihnen das sehr vertraut vorkommen. Stellen Sie sich vor, Sie wetten auf fallende Temperaturen und sehen, dass eine neue Transaktion mit höheren Temperaturen kommt, die Ihre Position ungültig machen könnte. Sie können einfach eine Transaktion mit höheren Gasgebühren senden, um das Orakel-Update vorwegzunehmen, und es mit den alten 25 °C direkt vor dem Update des Orakels auf 26 °C bestätigen lassen. 

Die Daten sind also nicht in Echtzeit, nach jeder gängigen Kennzahl, mit der wir den Begriff „Echtzeit“ definieren. Die Daten sind größtenteils veraltet und die Informationen sind öffentlich und sichtbar, bevor sie bestätigt werden. 

Selbst bei immer kleineren Schwellenwerten und/oder schnelleren Herzschlägen skaliert diese Architektur nicht gut. Lassen Sie uns ins Extreme gehen und sagen, wir möchten traditionelle US-Aktienmarktdaten on-chain bringen. Es ist nicht ungewöhnlich, dass eine Aktie mehrere tausend oder zigtausend Mal pro Sekunde gehandelt wird, wobei sich der Preis nur geringfügig in Cent nach oben oder unten ändert. Auf Ethereum wird eine Transaktion (derzeit) alle ~14 Sekunden bestätigt. Auf Polygon ist es viel schneller. Es ist nicht nur die Transaktionsdurchsatzrate, sondern auch die Bestätigungszeit, die zählt. Zehntausende von Updates pro Sekunde – und pro Markt – sind mit dieser Architektur nicht machbar. Die Aktualisierung der on-Chain-Informationen auf Push-Basis funktioniert einfach nicht, wenn Daten in Echtzeit auf der Blockchain sein müssen. Abgesehen von der Netzwerküberlastung zeigt eine einfache Rechnung zu den Kosten aller Transaktionen, selbst wenn sie bei 0,001 Cent pro Transaktion liegen, dass es nicht möglich sein wird, alle Preisupdates mit einer ausreichend hohen Abtastrate zu bewältigen, um Unternehmen, die auf Echtzeitdaten angewiesen sind, gerecht zu werden.

Pull-Orakel

Hier kommen Pull-Orakel ins Spiel. Ein Pull-Orakel kehrt das Problem der Datenabhängigkeit um. Anstatt die Daten on-chain verfügbar zu machen, stellt ein Pull-Orakel sie off-chain mit Signaturmechanismen bereit, um die Validität der Daten zu überprüfen.

Sie abonnieren einen regelmäßigen http/websocket-Datenfeed. Sie erhalten Echtzeit-Updates. Und wenn Sie einen Preis benötigen, verwenden Sie die Daten in Ihrer eigenen Transaktion. Die Daten werden Ihnen in einer Weise zur Verfügung gestellt, dass Sie nicht mit den Daten manipulieren können.

Lassen Sie uns zum Beispiel mit der Temperatur und der Wette auf die Temperatur zurückkehren. Es gibt das Orakel (O) und den Teilnehmer oder Benutzer (U) sowie den Markt (M).

O hat die Daten. U möchte auf M handeln. Anstatt die Daten on-chain abzufragen, erhält der Benutzer U die Temperatur von O off-chain. Aber O sendet nicht einfach die aktuelle Temperatur, sondern übermittelt sie mit einer kryptografischen Signatur, sodass M (oder jemand anderes) überprüfen kann, dass sie nicht manipuliert wurde. Nun sendet der Benutzer die Transaktion on-chain, die die Daten vom Orakel an den Markt enthält, der dann bestätigen kann, dass der Datenpunkt tatsächlich vom off-chain-Orakel stammt und Ihnen erlaubt, zu handeln, was immer Sie handeln möchten. 

Dies skaliert gut, bringt jedoch zwei weitere, sehr große Probleme mit sich:

1. Auf der Seite des Benutzers/Marktes kann der Benutzer die Daten sehen, bevor sie gesendet werden. Der Benutzer fragt die Daten ab und, obwohl er die Daten nicht manipulieren kann, kann er entscheiden, ob er die Transaktion senden möchte oder nicht.
2. Die Daten sind öffentlich verfügbar, was ein Problem für die Datenlizenzierung und die Datenrechte darstellt. Viele Daten, insbesondere Finanzdaten, sind eng lizenziert für Verbreitung, Anzeige und andere Rechte. Wenn das Orakel selbst Daten sichtbar machen muss und diese über einen Socket verbreitet, bedeutet dies in der Regel, dass traditionelle Datenanbieter keine (und auch nicht bereit sind,) Daten über dieses Orakel bereitzustellen.

Das Morpher-Orakel unterscheidet sich von beiden Ansätzen. 

Das absichtsbasiertes System baut auf Account-Abstraktion, auch bekannt als ERC4337, auf. ERC4337 hat nichts mit Orakeln zu tun, ist jedoch die Technologie, die Morpher nutzt, um seine Orakeltechnologie darauf aufzubauen und die beiden verbleibenden Probleme mit Pull-Orakeln zu lösen.

Kontoabstraktion: ein kurzer tiefer Einblick

Die Kontoabstraktion löst ein unabhängiges Problem zu Orakeln, aber ein lang bestehendes Problem für EVM (Ethereum Virtual Machine) basierte Systeme. 

In EVM-basierten Systemen benötigt eine gesendete Transaktion „Gas“ – jemanden, der die Transaktion bezahlt. Transaktionen sind nicht kostenlos und sind ein entscheidender wirtschaftlicher Bestandteil der Funktionsweise der Blockchain sowie der Bezahlung ihrer Validatoren oder Miner. 

In aktuellen EVM-basierten Systemen gibt es zwei Arten von Konten: EOA (extern verwaltete Konten) und Vertragskonten. EOAs sind die Konten, die Sie normalerweise in Ihrer Wallet sehen, die durch einen privaten Schlüssel kontrolliert werden. Vertragskonten sind Smart Contracts. 

Nur EOAs können auf Ethereum Transaktionen bezahlen. Und dies kann nicht delegiert werden. Ich kann nicht sagen: „Ich möchte diese Transaktion senden, aber ich möchte, dass [ein anderes Konto] dafür bezahlt.“ Dieses Problem wurde seit Jahren versucht zu lösen, indem ein Konstrukt mit dem Namen „Kontoabstraktion“ geschaffen wurde. Der Begriff bedeutet allgemein, dass die Grenze zwischen EOAs und Verträgen verschwommen wird, wobei möglicherweise Verträge selbst für Transaktionen bezahlen können. 

In den ersten Entwurf(en) der Kontoabstraktion (es gab viele Entwürfe, die nie in Produktion gingen) konnte ein Vertrag für Transaktionen bezahlen. Es stellte sich jedoch heraus, dass es ein sehr komplexes Problem ist, das mit sehr tiefgreifenden Änderungen an der Architektur der Blockchain und der Knoten selbst verbunden ist, wahrscheinlich mit einer Reihe von Hard Forks und brechenden Updates sowie allgemein mit dem Konsens der Gemeinschaft.

Dann kam ein weiterer Vorschlag – Vorschlag Nummer 4337, oder ERC4337. Hier waren keine Änderungen an der Blockchain selbst erforderlich. Es war voll rückwärtskompatibel und relativ einfach zu implementieren. 

Die Idee war, eine Reihe von verschiedenen Signaturmechanismen sowie Off-Chain- und On-Chain-Teilnehmern zu nutzen, um das Senden der Transaktion zu delegieren. 

Jeder der Teilnehmer hätte eine distinct Funktion und kann entweder die Daten nicht manipulieren oder, hauptsächlich durch Spieltheorie, möchte die Daten nicht zurückhalten.

Lassen Sie uns ein konkretes Beispiel machen.

In der Welt von ERC4337 gibt es eine Reihe von Teilnehmern. 

1. Es gibt Sie, den Benutzer, der eine Transaktion senden möchte. 
2. Es gibt einen Bundler, der ein Softwarestück ist, das sogenannte Benutzeroperationen entgegennimmt, die sehr ähnlich wie reguläre Transaktionen sind, aber noch nicht bezahlt wurden. 
3. Es gibt einen Paymaster, der jemand ist, der Ihre Transaktion bezahlen könnte. Dies ist der entscheidende Teil, wo Sie die Zahlung für Transaktionen an jemand anderen delegieren können. Diese Person kann dann sicherstellen, dass sie entweder Off-Chain oder direkt und transparent On-Chain von Ihnen bezahlt wird. 
4. Es gibt einen Einstiegspunkt, der ein Smart Contract ist, der hauptsächlich Signaturen validiert und sicherstellt, dass jeder korrekt bezahlt wird. 
5. Es gibt eine On-Chain-Wallet, ein sogenanntes Smart-Konto, das wiederum ein weiterer Smart Contract ist. Smart-Konten existierten bereits vor ERC4337 und werden parallel oder unabhängig von der Kontoabstraktion entwickelt, sie ergänzen sich einfach. Es sind Smart Contracts, die sich wie reguläre Wallets verhalten, die dann einfach durch ein extern verwaltetes Konto (ein Konto, das durch einen privaten Schlüssel kontrolliert wird) gesteuert werden. 
6. Dann gibt es den endgültigen Vertrag, mit dem Sie interagieren möchten.

Der entscheidende Punkt bei ERC4337 ist, dass nicht Sie, mit Ihrem extern verwalteten Konto, mit dem endgültigen Vertrag interagieren, sondern Sie weisen Ihre On-Chain-Wallet an, mit dem endgültigen Vertrag zu interagieren, mit dem Sie interagieren möchten.

Im Allgemeinen wird empfohlen, On-Chain-Wallets anstelle von EOAs zu verwenden, unabhängig davon, ob die Kontoabstraktion verwendet wird oder nicht. Zum Beispiel https://safe.global/: Es bietet viele Vorteile, wie Multi-Signatur-Autorisierung, soziale Wiederherstellung und vieles mehr. Obwohl dies den Rahmen dieses Artikels sprengt, bewegt sich die Bewegung allgemein in Richtung On-Chain-Wallets.

Für unser Beispiel nehmen wir an, Sie möchten 1 ETH von Ihrer Smart-Wallet an jemand anderen senden. Aber anstatt direkt mit Ihrer Smart-Wallet zu interagieren, möchten Sie dies auf eine „gaslose“ Weise tun. Das bedeutet, Ihr EOA könnte 0 ETH haben, um die Transaktion zu bezahlen, aber Sie möchten dennoch Ihre On-Chain-Wallet irgendwie anweisen, die 1 ETH in Ihrem Namen von sich selbst an jemand anderen zu senden.

Dies funktioniert, indem eine Benutzeroperation (UserOperation, userOp) erstellt wird. Eine userOp sieht strukturell sehr ähnlich wie eine reguläre Transaktion aus.

Lassen Sie uns dies etwas genauer betrachten, um ein besseres Verständnis zu erhalten:

1. Es hat einen Absender, der Ihr Smart-Konto ist. 
2. Es hat eine Nonce, die eine ständig wachsende Zahl ist. Sehr ähnlich wie bei einer normalen Transaktion, jedoch erhalten Sie diese nicht von den Blockchain-Knoten selbst, sondern von dem Einstiegspunkt. 
3. Es hat einen InitCode, der ein Smart-Konto (On-Chain-Wallet) erstellt, falls Sie noch keines haben. 
4. Es hat CallData, die ähnlich wie der Datenanteil in einer regulären Transaktion ist. Dieser Teil weist Ihre Smart-Wallet an, in Ihrem Namen etwas zu tun.
5. Dann hat es eine Reihe von Gas-Variablen, um zu bestimmen, wie viel an den Bundler zu zahlen ist. 
6. Dann gibt es einen Paymaster, der ein weiterer Teilnehmer ist, der die Transaktion bezahlen könnte.
7. Die Signatur ist ein kryptografischer Mechanismus, um die userOp manipulationssicher zu machen. Es handelt sich um ein Nachrichtensignaturverfahren vom extern verwalteten Konto, bei dem das gesamte userOp signiert wird, ohne es als Transaktion zu senden.

Dann sind wir fertig. Diese wird an den Bundler gesendet.

Ein Bundler ist ein Softwarestück, das im Grunde nur einen Zweck hat: Er nimmt userOps (eine oder mehrere davon, das ist wichtig!), verpackt sie in eine echte Transaktion, für die er bezahlt, und sendet sie an den Einstiegspunkt. Der Bundler ist keine Wohltätigkeitsorganisation, er sendet die userOps nicht, ohne dafür bezahlt zu werden. Hier kommen die Gas-Variablen in der userOp ins Spiel. Der Einstiegspunkt verwendet diese Variablen, um zu bestimmen, wie viel er dem Bundler „zurückzahlen“ soll. 

Da dies im Voraus bekannt ist, kann der Bundler auch vor dem Senden der tatsächlichen Transaktion überprüfen, ob er genügend bezahlt wird (gleich oder mehr als die Kosten für das Senden der tatsächlichen Transaktion). Schließlich sollte der Betrieb eines Bundlers wirtschaftlich sinnvoll sein.

Dann leitet der Einstiegspunkt die Absicht des Benutzers mit den CallData an den Absender (die Smart-Wallet des Benutzers) weiter, und die Smart-Wallet führt die Aktion aus, die der Benutzer durchführen wollte. Natürlich ist alles signiert, doppelt signiert und dreifach signiert, sodass niemand in der Lage ist, Daten zu manipulieren. Da jeder auf dem Weg einen kleinen, aber ansehnlichen Gewinn erzielt, gibt es auch keinen Grund zu glauben, dass sie absichtlich zusammenarbeiten würden, um eine Transaktion zurückzuhalten.

Die Bundler selbst sind über ein Netzwerk verbunden, in dem sie ausstehende Benutzeroperationen teilen, ähnlich einem tatsächlichen Transaktionspool auf Ethereum.

Der interessante Teil für das Oracle ist: Ein Bundler kann eine oder mehrere userOps in der gleichen Transaktion senden. Es handelt sich also um eine Transaktion, die mehrere userOps umschließt.

Der Morpher Oracle

Dies ist das, was der Morpher Oracle verwendet, um Preisinformationen oder einen Datenpunkt in das System einzuspeisen.

In einem regulären Kontoabstraktionsschema interagiert der Nutzer mit einem Bundler, indem er eine POST-Anfrage an eine bestimmte URL sendet. Der Bundler nimmt diese NutzerOp entgegen und fügt sie seinem Transaktionspool hinzu.

Im Morpher Oracle interagiert der Nutzer ebenfalls mit einem Bundler, jedoch sendet der Nutzer anstelle einer NutzerOp eine leicht andere Anfrage, die als DatenOp bezeichnet wird.

Die DatenOp sieht genau wie die NutzerOp aus, aber bevor die Transaktion genau so an den Endpunkt gesendet wird, injiziert der Bundler diesen Datenpunkt als NutzerOp vor der tatsächlichen NutzerOp des Nutzers. Dies wird durch den Vertrag bestimmt, mit dem der Nutzer interagiert, und kann eine neue Anforderung für die Interaktion festlegen:

Auf der Off-Chain-Seite wird vor dem Versenden der Transaktion überprüft, ob der Vertrag zusätzliche Daten benötigt, und dann wird dies als NutzerOp injiziert.

Dies ist eine atomare Operation; es gibt nicht zwei Transaktionen, sondern nur eine einzige Transaktion, die mit zwei (oder mehr) NutzerOps an den Einstiegspunkt gesendet wird. Die erste NutzerOp aktualisiert den Oracle, sehr ähnlich einem Push-Oracle, jedoch auf der Basis von Intentionen, bei der die Daten aus der Sicht des Nutzers in Echtzeit stammen. Die zweite NutzerOp ist die NutzerOp des Nutzers, die dann mit seiner Smart Wallet interagiert, die mit dem endgültigen Vertrag interagiert, der die Oracle-Daten aus dem Oracle-Vertrag liest.

Der Oracle selbst kann sicherstellen, dass er ebenfalls durch ein ähnliches, transparentes, on-chain Zahlungsschema bezahlt wird, wobei die Interaktion mit dem Oracle dann nicht kostenlos ist.

Die Daten sind nicht nur manipulationssicher aus der Sicht des Nutzers und des endgültigen Vertrags. Es ist auch nicht möglich, Daten zurückzuhalten, da sie privat sind. Ein Nutzer kann die Daten nicht sehen, bevor sie an den endgültigen Vertrag on-chain gesendet werden. Darüber hinaus sind die meisten, wenn nicht alle, Lizenzierungsfragen für Datenanbieter gelöst, da die Daten privat bleiben. Es sind keine Anzeige- oder Vertriebsrechte erforderlich. Die Daten bleiben nur für den empfangenden endgültigen Vertrag, der den Datenpunkt benötigt und dafür bezahlt, lesbar.

Neugierig, wie intendierte Oracles funktionieren? Sehen Sie es live im Morpher Oracle.

Wollen Sie tiefer in die Diskussion eintauchen? Treten Sie unserer Telegram-Gruppe bei.

Haftungsausschluss: Alle Investitionen sind mit Risiken verbunden und die bisherige Performance eines Wertpapiers, einer Branche, eines Sektors, eines Marktes, eines Finanzprodukts, einer Handelsstrategie oder des Handels einer Einzelperson ist keine Garantie für zukünftige Ergebnisse oder Erträge. Anleger sind voll verantwortlich für alle von ihnen getroffenen Anlageentscheidungen. Solche Entscheidungen sollten ausschließlich auf einer Bewertung ihrer finanziellen Umstände, Anlageziele, Risikobereitschaft und Liquiditätsbedürfnisse basieren. Dieser Beitrag stellt keine Anlageberatung dar