Was macht Morpher Oracle anders als traditionelle Orakel?

Blockchains sind geschlossene Systeme. Smart Contracts sind Programme, die innerhalb dieses Sandkastens ausgeführt werden. Solange sie nur miteinander interagieren, funktioniert alles einwandfrei. Für viele vorgeschlagene Anwendungsfälle in der realen Welt benötigen diese Programme jedoch Daten von außerhalb der Blockchain.

Lassen Sie uns ein Beispiel wählen: die Abwicklung einer Wette ist ein bekanntes Beispiel.

Mit der US-Wahl 2024, die gerade hinter uns liegt, wollen wir einen Smart Contract betrachten, der während des Präsidentschaftswahlkampfs äußerst erfolgreich war: Polymarket.

Entdecken Sie Morpher Oracle

Wie Blockchain-Wettmärkte funktionieren

Mit Wettmärkten können Sie auf die Wahrscheinlichkeit von realen Ereignissen wetten. Vor den Ergebnissen der Wahlen 2024 gab es ein Rennen zwischen Kamala Harris und Donald Trump. Der Smart Contract funktioniert, indem er den Menschen ermöglicht, Geld auf den Sieg oder die Niederlage einer der beiden Seiten zu setzen.

Vereinfacht gesagt: Wenn 10 Personen jeweils 1 Dollar auf Harris' Sieg setzen und 5 Personen jeweils 1 Dollar auf Harris' Niederlage setzen, hätten wir etwa 66% (oder 10 Dollar/15 Dollar) für Harris' Sieg und 33% für Harris' Niederlage. Sie könnten auf die Wette setzen, dass Harris verliert, für 0,33 Dollar, und so weiter. Es ist etwas komplizierter als das, aber hier kommen Orakel wie das Morpher-Orakel ins Spiel: Wie bestimmen Sie auf der Blockchain, wer gewonnen hat?

Das Oracle-Problem: Wer liefert vertrauenswürdige Daten?

Die Frage ist also: Wer hat, wenn überhaupt, die Autorität, auf der Blockchain bekannt zu geben, dass Trump oder Harris gewonnen hat? Und warum sollten wir dieser Person oder Entität vertrauen?

In der realen Welt ist das einfach: Man schaut die Nachrichten und wartet, bis die Stimmen ausgezählt sind.

Aber das Ergebnis auf die Blockchain zu bringen, ist ziemlich komplex.

Unter anderem gibt es einige gängige Optionen:

• Sie vertrauen einer einzelnen Person, die das korrekte Ergebnis bekannt gibt.
• Sie vertrauen einer Gruppe von Personen und aggregieren deren Ergebnisse.
• Sie erlauben jemandem, ein Ergebnis vorzuschlagen, und lassen andere diesen Vorschlag anfechten.

Die erste Option ist problematisch. In diesem Fall hängt das Schicksal vieler Menschen von einer einzigen Person ab. Dies würde nur funktionieren, wenn diese Person ein erhebliches Eigeninteresse hat und sicherstellen kann, dass das Ergebnis korrekt ist, möglicherweise durch das Setzen einer Kaution. Sobald dies jedoch geschieht, neigt es allmählich zur dritten Option, bei der das Ergebnis lediglich ein Vorschlag ist, der angefochten werden kann.

Das ist im Wesentlichen wie Polymarket funktioniert: Wenn eine Wette endet und eine Lösung erforderlich ist, kann jemand ein Ergebnis vorschlagen und eine Kaution setzen. Wenn das Ergebnis von der Community angefochten wird, kann die Kaution beansprucht werden. Wenn innerhalb eines bestimmten Zeitraums kein Streit entsteht, wird das Ergebnis als „die Wahrheit“ akzeptiert und die Wetten werden abgewickelt.

Die Herausforderung des Vertrauens in kleinen oder keinen Gemeinschaften

Bei Polymarket funktioniert dieses System gut. Zunächst wird der aktuelle Preis für eine Wette auf Gewinn/Verlust durch den Gesamtbetrag bestimmt, der auf jeder Seite ausgegeben wurde. Das bedeutet, dass bis zur Abwicklung keine externen Daten benötigt werden, um die Wette zu bepreisen. Darüber hinaus stellt die große Community sicher, dass böswillige Vorschläge zur Lösung und die Vermeidung von Streitigkeiten durch Mehrheitskontrolle kein wesentliches Problem darstellen.

Aber was ist, wenn es nur eine kleine Gemeinschaft gibt? Oder gar keine Gemeinschaft, und etwas zwischen nur zwei Parteien geklärt werden muss? Wem vertrauen Sie?

Wie reale Daten die Blockchain erreichen

Angenommen, Sie sind ein Versicherungsunternehmen, das Schadensfälle regulieren möchte. Sie versichern eine Lieferkette für frisches Fleisch, das von Asien in die USA transportiert wird. Anstatt sich auf eine Abteilung zu verlassen, die Versicherungsansprüche bearbeitet, implementieren Sie einen neuartigen „Schaden-Smart-Contract“, der automatisch auszahlt, sobald bestimmte Kriterien erfüllt sind.

In einem einfachen Beispiel könnte dieses Kriterium der Ausfall der Kühleinrichtungen des Schiffs während des Transports des Fleisches sein. Aber wie wissen diese Smart Contracts, dass die Einrichtungen ausgefallen sind? Sie benötigen Sensordaten.

Die Idee ist einfach: Wenn die Temperatursensoren im Lagerraum einen bestimmten Schwellenwert erreichen, gelten die Waren als verdorben, und die Versicherungszahlung wird ausgelöst. Natürlich würde es in einem realen Szenario mehrere Sensoren geben, die verschiedene Bedingungen innerhalb und außerhalb des Produkts überwachen. Aber um die Dinge einfach zu halten, konzentriert sich dieses Beispiel darauf, wie das System funktioniert.

Wie gelangen diese Sensordaten auf die Blockchain? Schließlich gibt es in diesem Fall nur zwei Akteure, also wer stellt sicher, dass die Daten zuverlässig sind? Idealerweise sollte keine der Parteien die alleinige Kontrolle haben, weshalb hier eine dritte Partei (oder noch besser, mehrere Drittparteien) ins Spiel kommt.

Was wäre, wenn die Daten nicht von einem einzelnen Sensor, sondern von einem gesamten Sensornetzwerk stammen würden? Was wäre, wenn mehrere Unternehmen beteiligt wären, die jeweils ihre eigenen Sensoren und unabhängige Messungen haben? Je mehr Quellen Daten beitragen, desto geringer ist das Risiko von Manipulationen, wodurch die Messungen zuverlässiger werden.

Stellen Sie sich vor, tausende von Unternehmen betten ihre eigene Sensortechnologie in Container, Produkte oder Verpackungen ein, die jeweils unabhängig Datenpunkte liefern. Wäre eine Aggregation dieser Messungen vertrauenswürdiger? Das wäre sie sicherlich, viel mehr, als sich auf eine einzige Person zu verlassen, die eine einzelne Messung in einem Containerschiff vornimmt und eine Transaktion einreicht.

Diese Art von aggregierten Sensordaten existiert bereits heute, wurde jedoch noch nicht in die Blockchain integriert.

Das führt zu einem weiteren Problem: Wem vertrauen wir, um diese Sensorablesungen zu aggregieren? Und können wir dieser Person auch vertrauen, die Transaktion zur Aktualisierung der Blockchain zu senden?

Wenn man ein paar Schritte vorausdenkt, sollten alle beteiligten Akteure „ausreichend dezentralisiert“ sein, um ein vertrauenswürdiges Umfeld zu schaffen. Je mehr unabhängige Teilnehmer Daten liefern, desto zuverlässiger wird das System.

Schwellenwertbasierte Datenübermittlung: Wie Push-Oracles funktionieren

Bis zur Erfindung des Morpher Oracles gab es zwei Hauptwege, um Daten auf die Blockchain zu bringen.

Gehen wir zurück zu unserem Beispiel mit den Sensorablesungen. Stellen Sie sich vor, das Schiff verlässt Asien, und eine erste Messung wird vorgenommen, die -15 °C aufzeichnet und den Beginn der Reise markiert. Diese erste Messung wird erfolgreich auf die Blockchain eingetragen.

Wir wissen jedoch, dass das Aktualisieren von Werten auf der Blockchain nicht kostenlos ist (zumindest normalerweise nicht). Außerdem haben Blockchains eine begrenzte Transaktionskapazität pro Sekunde. Berücksichtigen Sie nun, wie viele Schiffe weltweit im Einsatz sind und wie häufig sie möglicherweise Sensorablesungen aufzeichnen, vielleicht Dutzende Male pro Minute oder sogar pro Sekunde. Wenn jede einzelne Messung eine Blockchain-Transaktion benötigte, würde das System schnell überlastet werden.

Eine mögliche Lösung? Senden Sie nur eine Transaktion, wenn ein bestimmter Schwellenwert erreicht wird.

So funktionieren Push-Oracles, wie Chainlink.

In diesem speziellen Fall interessieren wir uns nur für eine Sensorablesung, wenn sich der Wert um 1–2 Grad Celsius ändert. Zusätzlich könnte alle 1–2 Stunden eine Herzschlag-Transaktion gesendet werden, wenn die Temperatur innerhalb des Schwellenwerts bleibt.

Für unseren Smart Contract würde er Sensorablesungen von einem anderen Smart Contract abrufen. Dieser Vertrag würde weiterhin -15 °C anzeigen, bis sich die Temperatur um 1 oder 2 Grad ändert, aktualisiert auf -13 °C usw. Unser Smart Contract würde dann zulassen, dass ein Anspruch geltend gemacht wird, wenn die Temperaturmessungen +5 °C oder höher erreichen. Dieser Prozess könnte vollständig automatisiert werden, und solange das Oracle (der Vermittler, der die Daten überträgt) ausreichend dezentralisiert ist, bleibt das System vertrauenswürdig.

Allerdings wird es hier knifflig. Push-Oracles können langsame Aktualisierungsintervalle haben. Während dies gut für Versicherungsansprüche funktionieren mag, bei denen eine Sensorablesung eine (teilweise) automatische Auszahlung auslöst, ist es für andere Anwendungsfälle nicht so effektiv.

Einer dieser Fälle? Echtzeitpreisinformationen auf der Blockchain.

Pull-Oracles: Ein neuer Ansatz für Echtzeitdaten

Um noch bessere Live-Daten zu erzielen, entstand eine andere Art von Oracle: das Pull-Oracle. In diesem Fall werden Daten außerhalb der Blockchain bereitgestellt, jedoch auf eine Weise, die es ermöglicht, ihre Authentizität zu überprüfen, auch wenn sie von einer untrusted Partei gesendet werden.

Das mag zunächst ungewöhnlich erscheinen, aber stellen Sie sich vor, Sie schreiben eine wichtige Information in einem Brief auf. Sie legen den Brief in einen Umschlag, versiegeln ihn und bringen ein Wachssiegel an. Dann senden Sie ihn per Post. Wenn der Empfänger den Umschlag erhält, kann er sofort erkennen, ob jemand in den Inhalt eingegriffen hat, nur indem er sich das Wachssiegel ansieht.

Ein reales Beispiel für dieses Konzept verwenden einige Unternehmen: Sie vakuumverpacken ein kleines Paket mit Bohnen oder bunten Murmeln in durchsichtiger Verpackung. Bevor sie es versenden, machen sie ein Foto und senden es per E-Mail an den Empfänger. Bei der Lieferung können Sie das Paket mit dem Foto vergleichen; wenn die Bohnen oder Murmeln genau wie abgebildet sind, ist das Paket unberührt. Aber wenn jemand damit herumgespielt hat, wäre es nahezu unmöglich, alles wieder in der genauen Anordnung zurückzulegen.

Das ist sehr ähnlich, wie Pull-Oracles funktionieren. Sie fordern einen Datenpunkt außerhalb der Blockchain an. Er wird kryptographisch signiert (das Wachssiegel), und dann senden Sie diese Daten selbst an den empfangenden Smart Contract. Der Smart Contract kann dann die kryptographische Signatur überprüfen, um sicherzustellen, dass die Daten authentisch und nicht verändert wurden.

Dieser Ansatz eignet sich hervorragend für nahezu Echtzeitdaten und wird heute von Unternehmen wie Pyth häufig genutzt.

Allerdings bringt das ein weiteres Problem mit sich: Sie sehen die Daten, bevor Sie sie senden, was bedeutet, dass Sie entscheiden können, ob Sie sie senden oder nicht. Dies ist besonders problematisch für Plattformen, die eine Art Hebelwirkung oder das Platzieren von großen Wetten basierend auf sich allmählich ändernden Daten ermöglichen.

Sie, als Überbringer der Nachricht, können entscheiden, ob Sie die Nachricht tatsächlich übermitteln. Das heißt, Sie fordern manipulationssichere Daten an, aber Sie können dennoch entscheiden, ob Sie sie senden oder nicht. Die Daten sind vor der Einreichung sichtbar und klar lesbar.

Das bringt zwei große Probleme mit sich:

• Erstens, während die Daten selbst, wenn sie gesendet werden, vertrauenswürdig sein können, gibt es keine Garantie, dass die Daten gesendet werden, wenn das Ergebnis für eine potenzielle Gegenpartei ungünstig ist.
• Zweitens führt es zu möglichen Problemen mit der Datenlizenzierung, da die Daten vor der Abwicklung auf der Blockchain sichtbar sein müssen.

Hier bringt das Morpher Oracle einen neuen Ansatz in die Architektur von Oracles ein. Es handelt sich um ein absichtsbasiertes Oracle, das einen Fortschritt gegenüber dem pull-basierten Modell darstellt.

Morpher Oracle: Eine neue Lösung für Blockchain-Datenfeeds

Mit dem Morpher Oracle ist der Nutzer nicht verantwortlich für das Senden einer Transaktion, sondern sendet stattdessen eine Absicht, eine Transaktion zu senden. Dies kehrt den Pull-Oracle-Mechanismus um:

• Der Nutzer legt seine Transaktion in einen Umschlag, versiegelt ihn mit einem Wachssiegel und übergibt ihn dem Oracle.
• Das Oracle kann den Inhalt des Umschlags nicht manipulieren.
• Das Oracle hat keinen Anreiz, die Transaktion zurückzuhalten, da es für das Senden bezahlt wird.
• Das Oracle sieht, dass der Nutzer aktuelle Informationen benötigt und kann einen vertrauenswürdigen Datenpunkt auf den Brief des Nutzers aufsetzen.

Dadurch ist der Nutzer garantiert, dass seine Transaktion gesendet wird. Der Smart Contract gewährleistet, dass die Informationen aktuell und kryptographisch signiert sind, ähnlich wie bei Pull-Oracles. Aber die Gegenpartei hat auch die Garantie, dass die Transaktion eingereicht wird, selbst wenn der Datenpunkt des Oracles für den Nutzer ungünstig ist, es ist ein faires Spiel.

Darüber hinaus können Daten nicht in großen Mengen abgezapft werden, was die Lizenzprobleme verhindert, mit denen traditionelle Pull-Oracles konfrontiert sind.

Treten Sie der Morpher Oracle Telegram-Gruppe für weitere Informationen bei.

Das Morpher Oracle gewährleistet Echtzeit-Datenfeeds, die manipulationssicher sind, ohne Manipulationen oder Verzögerungen – und garantiert faire, vertrauenslose Transaktionen on-chain. Testen Sie es jetzt auf BNB und Radix.

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