Orakel

Oracles sind Anwendungen, die Datenfeeds erstellen, um Off-Chain-Datenquellen für Smart Contracts auf der Blockchain verfügbar zu machen. Dies ist notwendig, da Ethereum-basierte Smart Contracts standardmäßig nicht auf Informationen zugreifen können, die außerhalb des Blockchain-Netzwerks gespeichert sind.

Durch die Möglichkeit, dass Smart Contracts mit Off-Chain-Daten ausgeführt werden können, wird die Nützlichkeit und der Wert dezentralisierter Anwendungen erweitert. Zum Beispiel stützen sich On-Chain-Prognosemärkte auf Orakel, um Informationen über Ergebnisse bereitzustellen, die sie zur Überprüfung von Benutzervorhersagen verwenden. Angenommen, Alice setzt 20 ETH darauf, wer der nächste US-Präsident wird. Präsident. In diesem Fall benötigt die Vorhersage-Markt-Dapp ein Orakel, um die Wahlergebnisse zu bestätigen und zu ermitteln, ob Alice für eine Auszahlung in Frage kommt.

Voraussetzungen

Diese Seite setzt voraus, dass der Leser mit den Grundlagen von Ethereum vertraut ist, einschließlich Nodes, Konsensmechanismen und der EVM. Sie sollten auch ein gutes Verständnis von Smart Contracts und der Anatomie von Smart Contracts haben, insbesondere von .

Was ist ein Blockchain-Orakel?

Oracles sind Anwendungen, die externe Informationen (d. h. Offchain gespeicherte Informationen) beschaffen, überprüfen und an Smart Contracts übermitteln, die auf der Blockchain ausgeführt werden. Neben dem „Abrufen“ von Off-Chain-Daten und dem Übertragen auf Ethereum können Orakel auch Informationen von der Blockchain an externe Systeme „pushen“, z. B. ein Smart Lock entsperren, sobald der Benutzer eine Gebühr über eine Ethereum-Transaktion sendet.

Ohne ein Oracle wäre ein Smart Contract vollständig auf On-Chain-Daten beschränkt.

Orakles unterscheiden sich in Bezug auf die Datenquelle (eine oder mehrere Quellen), Vertrauensmodelle (zentralisiert oder dezentralisiert) und Systemarchitektur (sofort-lesen, publish-subscribe und request-response). Wir können auch zwischen Orakeln unterscheiden, je nachdem, ob sie externe Daten für die Nutzung durch On-Chain-Verträge abrufen (Input-Orakel), Informationen von der Blockchain zu Off-Chain-Anwendungen senden (Output-Orakel) oder rechnerische Aufgaben außerhalb der Blockchain ausführen (Computational-Orakel).

Warum benötigen Smart Contracts Orakel?

Viele Entwickler betrachten Smart Contracts als Code, der an spezifischen Adressen auf der Blockchain ausgeführt wird. Eine allgemeinere Sichtweise auf Smart Contracts ist jedoch, dass es sich um selbstausführende Softwareprogramme handelt, die in der Lage sind, Vereinbarungen zwischen Parteien durchzusetzen, sobald bestimmte Bedingungen erfüllt sind – daher der Begriff „Smart Contracts“.

Die Verwendung von Smart Contracts zur Durchsetzung von Vereinbarungen zwischen Personen ist aufgrund der Deterministik von Ethereum nicht einfach. Ein deterministisches Systemopens in a new tab ist eines, das bei einem gegebenen Anfangszustand und einer bestimmten Eingabe immer die gleichen Ergebnisse liefert, was bedeutet, dass es bei der Berechnung von Ausgaben aus Eingaben keine Zufälligkeit oder Variation gibt.

Um eine deterministische Ausführung zu erreichen, beschränken Blockchains die Nodes darauf, einen Konsens über einfache binäre (wahr/falsch) Fragen zu erzielen, indem sie ausschließlich Daten verwenden, die auf der Blockchain selbst gespeichert sind. Beispiele für solche Fragen umfassen:

„Hat der Kontoinhaber (identifiziert durch einen öffentlichen Schlüssel) diese Transaktion mit dem zugehörigen privaten Schlüssel signiert?“
„Verfügt dieses Konto über ausreichende Mittel, um die Transaktion abzudecken?“
„Ist diese Transaktion im Kontext dieses Smart Contracts gültig?“, usw.

Wenn Blockchains Informationen von externen Quellen (d.h. aus der realen Welt) erhielten, wäre eine deterministische Ausführung unmöglich zu erreichen, was die Nodes daran hindern würde, sich über die Gültigkeit von Änderungen am Zustand der Blockchain einig zu werden. Nehmen Sie zum Beispiel einen Smart Contract, der eine Transaktion basierend auf dem aktuellen ETH-USD Wechselkurs ausführt, der von einer traditionellen Preis-API bezogen wird. Diese Zahl wird wahrscheinlich häufig ändern (ganz zu schweigen davon, dass die API veraltet oder gehackt werden könnte), was bedeutet, dass Knoten, die denselben Vertragscode ausführen, zu unterschiedlichen Ergebnissen kommen würden.

Für eine öffentliche Blockchain wie Ethereum, mit Tausenden von Nodes weltweit, die Transaktionen verarbeiten, ist Determinismus von entscheidender Bedeutung. Ohne eine zentrale Autorität als Quelle der Wahrheit benötigen Nodes Mechanismen, um nach der Anwendung derselben Transaktionen zum gleichen Zustand zu gelangen. Ein Fall, in dem Node A einen Smart Contract ausführt und als Ergebnis "3" erhält, während Node B "7" erhält, nachdem er dieselbe Transaktion ausgeführt hat, würde den Konsens zusammenbrechen lassen und den Wert von Ethereum als dezentralisierte Computing-Plattform zunichte machen.

Dieses Szenario hebt auch das Problem hervor, das mit dem Entwurf von Blockchains entsteht, um Informationen aus externen Quellen zu beziehen. Orakel lösen dieses Problem jedoch, indem sie Informationen aus Off-Chain-Quellen entnehmen und diese auf der Blockchain speichern, damit Smart Contracts sie nutzen können. Da auf der Blockchain gespeicherte Informationen unveränderlich und öffentlich zugänglich sind, können Ethereum-Nodes die vom Oracle importierten Off-Chain-Daten sicher verwenden, um Zustandsänderungen zu berechnen, ohne den Konsens zu brechen.

Um dies zu erreichen, besteht ein Oracle in der Regel aus einem Smart Contract, der auf der Blockchain läuft, und einigen Off-Chain-Komponenten. Der On-Chain-Vertrag erhält Anfragen nach Daten von anderen Smart Contracts, die er an die Off-Chain-Komponente (auch Oracle-Node genannt) weiterleitet. Dieser Oracle-Node kann Datenquellen abfragen – beispielsweise unter Verwendung von Anwendungsprogrammierschnittstellen (APIs) – und Transaktionen senden, um die angeforderten Daten im Speicher des Smart Contracts zu speichern.

Im Wesentlichen überbrückt ein Blockchain-Oracle die Informationslücke zwischen der Blockchain und der externen Umgebung, wodurch „hybride Smart Contracts“ entstehen. Ein hybrider Smart Contract ist einer, der auf einer Kombination aus On-Chain-Vertragscode und Off-Chain-Infrastruktur basiert. Dezentrale Prognosemärkte sind ein hervorragendes Beispiel für hybride Smart Contracts. Andere Beispiele könnten Smart Contracts für Ernteversicherungen sein, die eine Zahlung leisten, wenn eine Gruppe von Orakeln feststellt, dass bestimmte Wetterphänomene eingetreten sind.

Was ist das Oracle-Problem? Das Oracle-Problem

Orakel lösen ein wichtiges Problem, führen aber auch einige Komplikationen ein, zum Beispiel.,:

Wie können wir überprüfen, dass die eingespeiste Information aus der richtigen Quelle extrahiert wurde oder nicht manipuliert wurde?
Wie stellen wir sicher, dass diese Daten immer verfügbar sind und regelmäßig aktualisiert werden?

Das sogenannte "Orakle-Problem" zeigt die Probleme auf, die mit der Verwendung von Blockchain-Orakeln zur Übermittlung von Eingaben an Smart Contracts verbunden sind. Die Daten von einem Orakel müssen korrekt sein, damit ein Smart Contract korrekt ausgeführt wird. Darüber hinaus untergräbt das notwendige 'Vertrauen' in die Betreiber von Orakeln, genaue Informationen zu liefern, den 'vertrauenslosen' Aspekt von Smart Contracts.

Different oracles offer different solutions to the oracle problem, which we explore later. Orakel werden typischerweise danach bewertet, wie gut sie die folgenden Herausforderungen bewältigen können:

Korrektheit: Ein Oracle sollte nicht dazu führen, dass Smart Contracts Zustandsänderungen auf Basis ungültiger Off-Chain-Daten auslösen. Ein Orakel muss die Authentizität und Integrität der Daten gewährleisten. Authentizität bedeutet, dass die Daten aus der richtigen Quelle stammen, während Integrität bedeutet, dass die Daten intakt geblieben sind (d. h. nicht verändert wurden), bevor sie onchain gesendet wurden.
Verfügbarkeit: Ein Orakel sollte keine Verzögerungen verursachen oder die Ausführung von Aktionen und das Auslösen von Zustandsänderungen durch Smart Contracts verhindern. Das bedeutet, dass die Daten von einem Orakel auf Anfrage ohne Unterbrechung verfügbar sein müssen.
Anreizkompatibilität: Ein Oracle sollte Off-Chain-Datenanbieter dazu anreizen, korrekte Informationen an Smart Contracts zu übermitteln. Anreizkompatibilität beinhaltet Zurechenbarkeit und Rechenschaftspflicht. Zurechenbarkeit ermöglicht die Verknüpfung eines Stücks externer Information mit ihrem Anbieter, während Verantwortlichkeit die Datenanbieter an die von ihnen gelieferten Informationen bindet, sodass sie basierend auf der Qualität der bereitgestellten Informationen belohnt oder bestraft werden können.

Wie funktioniert ein Blockchain-Orakel-Dienst? Wie funktioniert ein Blockchain-Oracle-Service?

Benutzer

Benutzer sind Entitäten (d.h. Smart Contracts), die Informationen benötigen, die extern zur Blockchain liegen, um bestimmte Aktionen abzuschließen. Der grundlegende Arbeitsablauf eines Orakel-Dienstes beginnt damit, dass der Benutzer eine Datenanfrage an den Orakel-Vertrag sendet. Datenanfragen werden gewöhnlich einige oder alle der folgenden Fragen beantworten:

Welche Quellen können Off-Chain-Nodes für die angeforderten Informationen konsultieren?
Wie verarbeiten Reporter Informationen aus Datenquellen und extrahieren nützliche Datenpunkte?
Wie viele Oracle Nodes können an der Datenabfrage teilnehmen?
Wie sollten Diskrepanzen in Berichten von Orakeln verwaltet werden?
Welche Methode sollte implementiert werden, um Einreichungen zu filtern und Berichte zu einem einzigen Wert zu aggregieren?

Oracle-Vertrag

Der Oracle-Vertrag ist die On-Chain-Komponente des Oracle-Dienstes. Der Oracle Contract ist die On-Chain-Komponente für den Oracle-Service. Dieser Vertrag kann auch einige Berechnungen auf den zurückgegebenen Datenpunkten durchführen, um einen aggregierten Wert zu erzeugen, der an den anfragenden Vertrag gesendet wird.

Der Orakelvertrag stellt einige Funktionen bereit, die von Client-Verträgen aufgerufen werden, wenn eine Datenanfrage gestellt wird. Nach Erhalt einer neuen Anfrage gibt der Smart Contract ein Log-Ereignis mit den Details der Datenanfrage aus. Dies benachrichtigt Offchain-Nodes, die das Protokoll abonniert haben (normalerweise mit etwas wie dem JSON-RPC-Befehl eth_subscribe), die dann die im Log-Ereignis definierten Daten abrufen.

Nachfolgend finden Sie einen Beispiel-Oracle-Vertragopens in a new tab von Pedro Costa. Dies ist ein einfacher Oracle-Dienst, der auf Anfrage von anderen Smart Contracts Off-Chain-APIs abfragen und die angeforderten Informationen auf der Blockchain speichern kann:

1pragma solidity >=0.4.21 <0.6.0;
2
3contract Oracle {
4  Request[] requests; //Liste der an den Vertrag gestellten Anfragen
5  uint currentId = 0; //ansteigende Anforderungs-ID
6  uint minQuorum = 2; //Mindestanzahl der zu erhaltenden Antworten, bevor das Endergebnis deklariert wird
7  uint totalOracleCount = 3; // Fest programmierte Oracle-Anzahl
8
9  // definiert eine allgemeine API-Anfrage
10  struct Request {
11    uint id;                            //Anforderungs-ID
12    string urlToQuery;                  //API-URL
13    string attributeToFetch;            //JSON-Attribut (Schlüssel), das in der Antwort abgerufen werden soll
14    string agreedValue;                 //Wert vom Schlüssel
15    mapping(uint => string) answers;     //von den Oracles bereitgestellte Antworten
16    mapping(address => uint) quorum;    //Oracles, die die Antwort abfragen (1=Oracle hat nicht abgestimmt, 2=Oracle hat abgestimmt)
17  }
18
19  //Ereignis, das das Oracle außerhalb der Blockchain auslöst
20  event NewRequest (
21    uint id,
22    string urlToQuery,
23    string attributeToFetch
24  );
25
26  //wird ausgelöst, wenn ein Konsens über das Endergebnis erzielt wird
27  event UpdatedRequest (
28    uint id,
29    string urlToQuery,
30    string attributeToFetch,
31    string agreedValue
32  );
33
34  function createRequest (
35    string memory _urlToQuery,
36    string memory _attributeToFetch
37  )
38  public
39  {
40    uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, ""));
41    Request storage r = requests[length-1];
42
43    // Fest programmierte Oracle-Adressen
44    r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1;
45    r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1;
46    r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1;
47
48    // ein Ereignis auslösen, das vom Oracle außerhalb der Blockchain erkannt wird
49    emit NewRequest (
50      currentId,
51      _urlToQuery,
52      _attributeToFetch
53    );
54
55    // Anforderungs-ID erhöhen
56    currentId++;
57  }
58
59  //vom Oracle aufgerufen, um seine Antwort aufzuzeichnen
60  function updateRequest (
61    uint _id,
62    string memory _valueRetrieved
63  ) public {
64
65    Request storage currRequest = requests[_id];
66
67    //prüfen, ob das Oracle in der Liste der vertrauenswürdigen Oracles ist
68    //und ob das Oracle noch nicht abgestimmt hat
69    if(currRequest.quorum[address(msg.sender)] == 1){
70
71      //markieren, dass diese Adresse abgestimmt hat
72      currRequest.quorum[msg.sender] = 2;
73
74      //durch das "Array" der Antworten iterieren, bis eine Position frei ist, und den abgerufenen Wert speichern
75      uint tmpI = 0;
76      bool found = false;
77      while(!found) {
78        //ersten leeren Slot finden
79        if(bytes(currRequest.answers[tmpI]).length == 0){
80          found = true;
81          currRequest.answers[tmpI] = _valueRetrieved;
82        }
83        tmpI++;
84      }
85
86      uint currentQuorum = 0;
87
88      //durch die Oracle-Liste iterieren und prüfen, ob genügend Oracles (Mindestquorum)
89      //für dieselbe Antwort wie die aktuelle gestimmt haben
90      for(uint i = 0; i < totalOracleCount; i++){
91        bytes memory a = bytes(currRequest.answers[i]);
92        bytes memory b = bytes(_valueRetrieved);
93
94        if(keccak256(a) == keccak256(b)){
95          currentQuorum++;
96          if(currentQuorum >= minQuorum){
97            currRequest.agreedValue = _valueRetrieved;
98            emit UpdatedRequest (
99              currRequest.id,
100              currRequest.urlToQuery,
101              currRequest.attributeToFetch,
102              currRequest.agreedValue
103            );
104          }
105        }
106      }
107    }
108  }
109}
Alles anzeigen

Oracle-Nodes

Der Oracle-Node ist die Off-Chain-Komponente des Oracle-Dienstes. Er extrahiert Informationen aus externen Quellen, wie zum Beispiel APIs, die auf Drittanbieterservern gehostet werden, und stellt diese On-Chain für die Nutzung durch Smart Contracts bereit. Oracle-Nodes hören auf Ereignisse aus dem On-Chain-Oracle-Vertrag und führen die in der Protokollmeldung beschriebene Aufgabe aus.

Eine häufige Aufgabe für Oracle-Nodes ist das Senden einer HTTP GETopens in a new tab-Anfrage an einen API-Dienst, das Parsen der Antwort, um relevante Daten zu extrahieren, das Formatieren in eine Blockchain-lesbare Ausgabe und das Senden onchain durch Einbindung in eine Transaktion an den Oracle-Vertrag. Der Orakel-Node kann auch verpflichtet sein, die Gültigkeit und Integrität der eingereichten Informationen mit „Echtheitsbeweisen“ zu bestätigen, die wir später näher betrachten.

Auch Computations-Oracles verlassen sich auf Off-Chain-Nodes, um rechenintensive Aufgaben auszuführen, die aufgrund von Gas-Kosten und Blockgrößenbeschränkungen nicht praktikabel On-Chain durchgeführt werden könnten. Zum Beispiel kann der Oracle-Node damit beauftragt werden, eine nachweislich zufällige Zahl zu generieren (z.B. für blockchain-basierte Spiele).

Oracle-Designmuster

Oracles gibt es in verschiedenen Typen, einschließlich Immediate-Read, Publish-Subscribe und Request-Response, wobei die beiden letzteren bei Ethereum-Smart-Contracts am beliebtesten sind. Hier beschreiben wir kurz die Publish-Subscribe- und Request-Response-Modelle.

Dieser Typ von Oracle stellt einen "Datenfeed" zur Verfügung, den andere Verträge regelmäßig für Informationen abrufen können. In diesem Fall wird erwartet, dass sich die Daten häufig ändern, sodass die Client-Verträge auf Aktualisierungen der Daten im Speicher des Oracles achten müssen. Ein Beispiel ist ein Oracle, das Nutzern die neuesten ETH-USD-Preisinformationen zur Verfügung stellt.

Request-Response-Oracles

Ein Request-Response-Setup ermöglicht es dem Client-Vertrag, beliebige Daten anzufordern, die über die von einem Publish-Subscribe-Oracle bereitgestellten Daten hinausgehen. Request-Response-Oracles sind ideal, wenn der Datensatz zu groß ist, um im Speicher eines Smart Contracts gespeichert zu werden, und/oder die Nutzer zu jedem Zeitpunkt nur einen kleinen Teil der Daten benötigen.

Obwohl komplexer als Publish-Subscribe-Modelle, sind Request-Response-Oracles im Grunde das, was wir im vorherigen Abschnitt beschrieben haben. Der Oracle wird eine On-Chain-Komponente haben, die eine Datenanfrage empfängt und diese an einen Off-Chain-Node zur Verarbeitung weiterleitet.

Benutzer, die Datenabfragen initiieren, müssen die Kosten für das Abrufen von Informationen aus der Off-Chain-Quelle übernehmen. Der Client-Vertrag muss auch Mittel bereitstellen, um die Gas-Kosten zu decken, die durch den Oracle-Vertrag beim Zurücksenden der Antwort über die in der Anfrage spezifizierte Callback-Funktion entstehen.

Zentralisierte vs. dezentralisierte Oracles

Zentralisierte Oracles

Ein zentralisierter Oracle wird von einer einzigen Entität kontrolliert, die für das Sammeln von Off-Chain-Informationen und das Aktualisieren der Daten im Oracle-Vertrag auf Anfrage verantwortlich ist. Zentralisierte Oracles sind effizient, da sie sich auf eine einzige Wahrheitsquelle stützen. Sie können besser funktionieren in Fällen, in denen proprietäre Datensätze direkt vom Besitzer mit einer weit akzeptierten Signatur veröffentlicht werden. Sie bringen jedoch auch Nachteile mit sich:

Geringe Korrektheitsgarantien

Bei zentralisierten Orakeln gibt es keine Möglichkeit zu bestätigen, ob die bereitgestellten Informationen korrekt sind oder nicht. Selbst "renommierte" Anbieter können unzuverlässig werden oder gehackt werden. Wenn das Orakel korrupt wird, führen Smart Contracts Ausführungen auf Basis fehlerhafter Daten durch.

Schlechte Verfügbarkeit

Zentralisierte Oracles garantieren nicht, dass Off-Chain-Daten immer für andere Smart Contracts verfügbar gemacht werden. Wenn der Anbieter sich entscheidet, den Dienst abzuschalten, oder ein Hacker die Off-Chain-Komponente des Oracles übernimmt, besteht für deinen Smart Contract das Risiko eines Denial-of-Service (DoS)-Angriffs.

Schlechte Anreizkompatibilität

Zentralisierte Orakel haben oft schlecht konzipierte oder nicht vorhandene Anreize für den Datenanbieter, genaue/unveränderte Informationen zu senden. Die Bezahlung eines Orakels für Korrektheit garantiert nicht dessen Ehrlichkeit. Dieses Problem wird größer, je mehr Wert von Smart Contracts kontrolliert wird.

Dezentralisierte Oracles

Dezentralisierte Orakel sind darauf ausgelegt, die Einschränkungen zentralisierter Orakel zu überwinden, indem sie einzelne Ausfallpunkte beseitigen. Ein dezentraler Oracle-Dienst besteht aus mehreren Teilnehmern in einem Peer-to-Peer-Netzwerk, die vor dem Senden an einen Smart Contract ein Konsens über die Off-Chain-Daten bilden.

Ein dezentralisiertes Oracle sollte (idealerweise) erlaubnisfrei, vertrauenslos und frei von der Verwaltung durch eine zentrale Partei sein; in der Realität ist die Dezentralisierung bei Oracles ein Spektrum. Es gibt halb-dezentralisierte Orakel Netzwerke wo jeder Teilnehmen kann, aber mit einem "Besitzer" welcher Knoten nach historischer Leistung erlaubt und entfernt. Vollständig dezentralisierte Orakelnetzwerke existieren ebenfalls: Diese funktionieren in der Regel als eigenständige Blockchains und verfügen über definierte Konsensmechanismen zur Koordination der Nodes und zur Bestrafung von Fehlverhalten.

Die Nutzung dezentralisierter Orakel bietet folgende Vorteile:

Hohe Korrektheitsgarantien

Dezentralisierte Orakel versuchen, die Korrektheit von Daten durch verschiedene Ansätze zu gewährleisten. Dazu gehört die Verwendung von Nachweisen, die die Authentizität und Integrität der zurückgegebenen Informationen bestätigen, sowie die Notwendigkeit, dass mehrere Akteure kollektiv die Gültigkeit der Off-Chain-Daten bestätigen.

Authentizitätsnachweise

Authentizitätsnachweise sind kryptografische Mechanismen, die eine unabhängige Überprüfung von Informationen ermöglichen, die aus externen Quellen abgerufen wurden. Diese Nachweise können die Quelle der Informationen validieren und mögliche Veränderungen der Daten nach deren Abruf erkennen.

Beispiele für Authentizitätsnachweise umfassen:

Transport Layer Security (TLS)-Nachweise: Oracle-Nodes rufen häufig Daten aus externen Quellen über eine sichere HTTP-Verbindung ab, die auf dem Transport Layer Security (TLS)-Protokoll basiert. Einige dezentralisierte Orakel verwenden Authentizitätsnachweise, um TLS-Sitzungen zu verifizieren (das heißt, den Informationsaustausch zwischen einem Node und einem bestimmten Server zu bestätigen) und um sicherzustellen, dass die Inhalte der Sitzung nicht verändert wurden.

Trusted Execution Environment (TEE)-Attestierungen: Eine Trusted Execution Environmentopens in a new tab (TEE) ist eine abgeschottete Rechenumgebung, die von den Betriebsprozessen ihres Host-Systems isoliert ist. TEEs stellen sicher, dass jeglicher Anwendungscode oder Daten, die in der Rechenumgebung gespeichert oder verwendet werden, ihre Integrität, Vertraulichkeit und Unveränderlichkeit bewahren. Benutzer können auch eine Attestierung erstellen, um zu beweisen, dass eine Anwendungsinstanz innerhalb der Trusted Execution Environment läuft.

Bestimmte Klassen dezentralisierter Orakel erfordern, dass Betreiber von Orakel-Nodes TEE-Attestierungen bereitstellen. Dies bestätigt dem Benutzer, dass der Node-Betreiber eine Instanz des Orakel-Clients in einer Trusted Execution Environment ausführt. TEEs verhindern, dass externe Prozesse den Code und die Daten einer Anwendung ändern oder lesen. Daher beweisen diese Attestierungen, dass der Orakel-Node die Informationen unverändert und vertraulich gehalten hat.

Konsensbasierte Validierung von Informationen

Zentralisierte Orakel stützen sich auf eine einzelne Quelle der Wahrheit, wenn sie Daten an Smart Contracts liefern, was die Möglichkeit der Veröffentlichung ungenauer Informationen mit sich bringt. Dezentrale Oracles lösen dieses Problem, indem sie auf mehrere Oracle-Nodes zurückgreifen, um Off-Chain-Informationen abzufragen. Durch den Vergleich von Daten aus mehreren Quellen reduzieren dezentrale Oracles das Risiko, ungültige Informationen an On-Chain-Verträge weiterzuleiten.

Dezentrale Oracles müssen jedoch mit Diskrepanzen in den von mehreren Off-Chain-Quellen abgerufenen Informationen umgehen. Um Unterschiede in den Informationen zu minimieren und sicherzustellen, dass die an den Orakel-Vertrag übergebenen Daten die kollektive Meinung der Orakel-Nodes widerspiegeln, verwenden dezentralisierte Orakel folgende Mechanismen:

Abstimmung/Einsatz bezüglich der Genauigkeit von Daten

Einige dezentralisierte Orakelnetzwerke erfordern, dass Teilnehmer über die Genauigkeit von Antworten auf Datenanfragen abstimmen oder Einsätze tätigen (z.B. "Wer hat die US-Wahl 2020 gewonnen?") unter Verwendung des nativen Tokens des Netzwerks. Ein Aggregationsprotokoll aggregiert dann die Stimmen und Einsätze und nimmt die von der Mehrheit unterstützte Antwort als die gültige an.

Ein Aggregationsprotokoll aggregiert dann die Stimmen und Einsätze und nimmt die von der Mehrheit unterstützte Antwort als die gültige an. Das Erfordern einer Kaution von den Nodes, bevor sie Daten bereitstellen, motiviert zu ehrlichen Antworten, da angenommen wird, dass sie rationale ökonomische Akteure sind, die darauf abzielen, ihre Erträge zu maximieren.

Staking/Abstimmungen schützen dezentrale Oracles auch vor , bei denen böswillige Akteure mehrere Identitäten erstellen, um das Konsenssystem zu manipulieren. Allerdings kann Staking „Trittbrettfahren“ (Nodes kopieren Informationen von anderen) und „faule Validierung“ (Nodes folgen der Mehrheit, ohne die Informationen selbst zu überprüfen) nicht verhindern.

Schelling-Punkt-Mechanismen

Ein Schelling-Punktopens in a new tab ist ein spieltheoretisches Konzept, das davon ausgeht, dass mehrere Entitäten bei fehlender Kommunikation immer auf eine gemeinsame Lösung für ein Problem zurückgreifen. Schelling-Punkt-Mechanismen werden häufig in dezentralen Orakel-Netzwerken verwendet, um Nodes zu ermöglichen, einen Konsens über Antworten auf Datenanfragen zu erreichen.

Eine frühe Idee dafür war SchellingCoinopens in a new tab, ein vorgeschlagener Datenfeed, bei dem die Teilnehmer Antworten auf „skalare“ Fragen (Fragen, deren Antworten durch eine Größenordnung beschrieben werden, z. B. „Wie hoch ist der Preis von ETH?“) zusammen mit einer Einlage einreichen. Benutzer, die Werte zwischen dem 25. und 75. Perzentilopens in a new tab angeben, werden belohnt, während diejenigen, deren Werte stark vom Medianwert abweichen, bestraft werden.

Obwohl es SchellingCoin heute nicht mehr gibt, nutzen eine Reihe dezentraler Oracles – insbesondere die Oracles des Maker-Protokollsopens in a new tab – den Schelling-Punkt-Mechanismus, um die Genauigkeit der Oracle-Daten zu verbessern. Jeder Maker-Oracle besteht aus einem Off-Chain-P2P-Netzwerk von Nodes ("Relayer" und "Feeds"), die Marktpreise für Sicherungsassets einreichen, sowie einem On-Chain-"Medianizer"-Vertrag, der den Median aller bereitgestellten Werte berechnet. Sobald die festgelegte Verzögerungszeit vorüber ist, wird dieser Medianwert zum neuen Referenzpreis für das zugehörige Asset.

Andere Beispiele für Oracles, die Schelling-Punkt-Mechanismen verwenden, sind Chainlink Offchain Reportingopens in a new tab und Witnetopens in a new tab. In beiden Systemen werden Antworten von Orakel-Nodes im Peer-to-Peer-Netzwerk zu einem einzigen aggregierten Wert wie einem Mittelwert oder Median zusammengefasst. Nodes werden entsprechend dem Grad belohnt oder bestraft, in dem ihre Antworten mit dem aggregierten Wert übereinstimmen oder von ihm abweichen.

Schelling-Punkt-Mechanismen sind attraktiv, da sie den On-Chain-Fußabdruck minimieren (es muss nur eine Transaktion gesendet werden), während gleichzeitig Dezentralisierung garantiert wird. Letzteres ist möglich, weil die Nodes die Liste der eingereichten Antworten signieren müssen, bevor sie in den Algorithmus eingespeist wird, der den Mittelwert/Medianwert berechnet.

Verfügbarkeit

Dezentrale Oracle-Dienste gewährleisten eine hohe Verfügbarkeit von Off-Chain-Daten für Smart Contracts. Dies wird erreicht, indem sowohl die Quelle der Off-Chain-Informationen als auch die Nodes, die für die Übertragung der Informationen On-Chain verantwortlich sind, dezentralisiert werden.

Dies gewährleistet Fehlertoleranz, da der Orakelvertrag sich auf mehrere Nodes (die sich auch auf mehrere Datenquellen stützen) verlassen kann, um Abfragen von anderen Verträgen auszuführen. Die Dezentralisierung auf der Ebene der Quelle und des Node-Betreibers ist entscheidend – ein Netzwerk von Oracle-Nodes, das Informationen aus derselben Quelle bereitstellt, wird auf dasselbe Problem stoßen wie ein zentralisiertes Oracle.

Es ist auch möglich, dass stake-basierte Oracles die Node-Betreiber bestrafen, die nicht schnell auf Datenanfragen reagieren. Dies incentiviert Orakel-Nodes erheblich, in fehlertolerante Infrastruktur zu investieren und Daten rechtzeitig bereitzustellen.

Gute Anreizkompatibilität

Dezentralisierte Oracles implementieren verschiedene Anreizdesigns, um byzantinischesopens in a new tab Verhalten unter Oracle-Nodes zu verhindern. Insbesondere erreichen sie Zurechenbarkeit und Rechenschaftspflicht:

Dezentralisierte Orakel-Nodes müssen häufig die Daten signieren, die sie als Antwort auf Datenanfragen bereitstellen. Diese Informationen helfen bei der Bewertung der historischen Leistung von Orakel-Nodes, sodass Nutzer unzuverlässige Orakel-Nodes bei Datenanfragen herausfiltern können. Ein Beispiel ist das Algorithmische Reputationssystemopens in a new tab von Witnet.
Dezentralisierte Orakel – wie zuvor erläutert – können verlangen, dass Nodes einen Einsatz auf ihre Überzeugung in die Wahrheit der von ihnen übermittelten Daten setzen. Wenn die Behauptung zutrifft, kann dieser Einsatz zusammen mit Belohnungen für ehrlichen Dienst zurückgegeben werden. But it can also be slashed in case the information is incorrect, which provides some measure of accountability.

Anwendungen von Oracles in Smart Contracts

Die folgenden sind häufige Anwendungsfälle für Orakel in Ethereum:

Abrufen von Finanzdaten

Dezentralisierte Finanzen (DeFi) ermöglichen Peer-to-Peer-Kreditvergabe, -aufnahme und den Handel mit Vermögenswerten. Dies erfordert oft das Einholen verschiedener Finanzinformationen, einschließlich Wechselkursdaten (zur Berechnung des Fiat-Werts von Kryptowährungen oder zum Vergleich von Token-Preisen) und Kapitalmarktdaten (zur Berechnung des Werts tokenisierter Vermögenswerte, wie Gold oder US-Dollar).

Ein DeFi-Kreditprotokoll muss beispielsweise die aktuellen Marktpreise für als Sicherheit hinterlegte Vermögenswerte (z. B. ETH) abfragen. Dies ermöglicht es dem Vertrag, den Wert der Sicherheitsvermögenswerte zu bestimmen und festzulegen, wie viel er vom System leihen kann.

Beliebte „Preis-Oracles“ (wie sie oft genannt werden) in DeFi umfassen Chainlink Price Feeds, den Open Price Feedopens in a new tab von Compound Protocol, die zeitgewichteten Durchschnittspreise (TWAPs)opens in a new tab von Uniswap und die Maker Oraclesopens in a new tab.

Entwickler sollten die Vorbehalte verstehen, die mit diesen Preis-Orakeln einhergehen, bevor sie sie in ihr Projekt integrieren. Dieser Artikelopens in a new tab bietet eine detaillierte Analyse dessen, was bei der Planung der Verwendung eines der genannten Preis-Oracles zu beachten ist.

Im Folgenden finden Sie ein Beispiel, wie Sie den aktuellen ETH-Preis in Ihrem Smart Contract unter Verwendung eines Chainlink-Preisfeeds abrufen können:

1pragma solidity ^0.6.7;
2
3import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol";
4
5contract PriceConsumerV3 {
6
7    AggregatorV3Interface internal priceFeed;
8
9    /**
10     * Network: Kovan
11     * Aggregator: ETH/USD
12     * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
13     */
14    constructor() public {
15        priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
16    }
17
18    /**
19     * Returns the latest price
20     */
21    function getLatestPrice() public view returns (int) {
22        (
23            uint80 roundID,
24            int price,
25            uint startedAt,
26            uint timeStamp,
27            uint80 answeredInRound
28        ) = priceFeed.latestRoundData();
29        return price;
30    }
31}
Alles anzeigen

Generierung nachweisbarer Zufälligkeit

Bestimmte Blockchain-Anwendungen, wie blockchain-basierte Spiele oder Lotteriesysteme, benötigen ein hohes Maß an Unvorhersehbarkeit und Zufälligkeit, um effektiv zu funktionieren. Jedoch eliminiert die deterministische Ausführung von Blockchains die Zufälligkeit.

Der ursprüngliche Ansatz war die Verwendung pseudozufälliger kryptografischer Funktionen wie blockhash, aber diese konnten von Minern manipuliert werdenopens in a new tab Lösung des Proof-of-Work-Algorithmus. Außerdem bedeutet Ethereums Umstellung auf Proof-of-Stake, dass Entwickler sich für die Onchain-Zufälligkeit nicht mehr auf blockhash verlassen können. Der RANDAO-Mechanismusopens in a new tab der Beacon Chain bietet stattdessen eine alternative Quelle für Zufälligkeit.

Es ist möglich, den Zufallswert Off-Chain zu generieren und ihn dann On-Chain zu senden, aber dies stellt hohe Vertrauensanforderungen an die Nutzer. Sie müssen glauben, dass der Wert tatsächlich durch unvorhersehbare Mechanismen erzeugt wurde und während der Übertragung nicht verändert wurde.

Oracles, die für Off-Chain-Berechnungen entwickelt wurden, lösen dieses Problem, indem sie zufällige Ergebnisse sicher Off-Chain generieren und diese zusammen mit kryptografischen Beweisen, die die Unvorhersehbarkeit des Prozesses bestätigen, On-Chain übertragen. Ein Beispiel ist Chainlink VRFopens in a new tab (Verifiable Random Function), ein nachweislich fairer und manipulationssicherer Zufallszahlengenerator (RNG), der für die Erstellung zuverlässiger Smart Contracts für Anwendungen nützlich ist, die auf unvorhersehbaren Ergebnissen beruhen.

Ergebnisse für Ereignisse erhalten

Mit Orakeln ist es einfach, Smart Contracts zu erstellen, die auf reale Ereignisse reagieren. Oracle-Dienste machen dies möglich, indem sie Verträgen erlauben, sich über Off-Chain-Komponenten mit externen APIs zu verbinden und Informationen aus diesen Datenquellen zu nutzen. Zum Beispiel könnte die zuvor erwähnte Vorhersage-App ein Oracle anfordern, um Wahlergebnisse von einer vertrauenswürdigen Off-Chain-Quelle (z. B. der Associated Press) zurückzuliefern.

Die Verwendung von Orakeln, um Daten basierend auf realen Ergebnissen abzurufen, ermöglicht andere neuartige Anwendungsfälle; beispielsweise benötigt ein dezentralisiertes Versicherungsprodukt genaue Informationen über Wetter, Katastrophen usw., um effektiv zu funktionieren.

Automatisierung von Smart Contracts

Smart Contracts werden nicht automatisch ausgeführt; vielmehr muss ein externes Eigentümerkonto (EOA) oder ein anderes Vertragskonto die richtigen Funktionen auslösen, um den Code des Vertrags auszuführen. In den meisten Fällen sind der Großteil der Funktionen des Vertrags öffentlich und können von externen Eigentümerkonten (EOAs) und anderen Verträgen aufgerufen werden.

Es gibt aber auch private Funktionen innerhalb eines Vertrags, die für andere unzugänglich sind, aber für die allgemeine Funktionalität einer Dapp entscheidend sind. Beispiele hierfür sind eine mintERC721Token()-Funktion, die regelmäßig neue NFTs für Benutzer prägt, eine Funktion zur Auszahlung von Gewinnen in einem Prognosemarkt oder eine Funktion zum Freischalten von gestaketen Token in einer DEX.

Entwickler müssen solche Funktionen in Intervallen auslösen, um die Anwendung reibungslos laufen zu lassen. Dies kann jedoch zu mehr verlorenen Stunden bei routinemäßigen Aufgaben für Entwickler führen, weshalb die Automatisierung der Ausführung von Smart Contracts attraktiv ist.

Einige dezentrale Oracle-Netzwerke bieten Automatisierungsdienste an, die es Off-Chain-Oracle-Nodes ermöglichen, Smart-Contract-Funktionen gemäß von den Nutzern definierten Parametern auszulösen. Üblicherweise erfordert dies die "Registrierung" des Zielvertrags beim Orakeldienst, die Bereitstellung von Mitteln zur Bezahlung des Orakelbetreibers und die Festlegung der Bedingungen oder Zeiten zum Auslösen des Vertrags.

Das Keeper Networkopens in a new tab von Chainlink bietet Optionen für Smart Contracts, um regelmäßige Wartungsaufgaben auf eine vertrauensminimierte und dezentralisierte Weise auszulagern. Lesen Sie die offizielle Keeper-Dokumentationopens in a new tab für Informationen darüber, wie Sie Ihren Vertrag Keeper-kompatibel machen und den Upkeep-Service nutzen können.

Wie man Blockchain-Oracles verwendet

Es gibt mehrere Oracle Anwendungen, die du in den Ethereum Dapp integrieren kannst:

Chainlinkopens in a new tab – Dezentrale Oracle-Netzwerke von Chainlink bieten manipulationssichere Eingaben, Ausgaben und Berechnungen zur Unterstützung fortschrittlicher Smart Contracts auf jeder Blockchain.

RedStone Oraclesopens in a new tab – RedStone ist ein dezentrales, modulares Oracle, das gasoptimierte Datenfeeds bereitstellt. Er spezialisiert sich darauf, Preisfeeds für aufstrebende Assets anzubieten, wie zum Beispiel Liquid-Staking-Token (LSTs), Liquid-Restaking-Token (LRTs) und Bitcoin-Staking-Derivate.

Chronicleopens in a new tab – Chronicle überwindet die aktuellen Einschränkungen bei der Übertragung von Daten onchain durch die Entwicklung wirklich skalierbarer, kosteneffizienter, dezentraler und verifizierbarer Oracles.

Witnetopens in a new tab – Witnet ist ein erlaubnisfreies, dezentrales und zensurresistentes Oracle, das Smart Contracts dabei hilft, auf Ereignisse in der realen Welt mit starken krypto-ökonomischen Garantien zu reagieren.

UMA Oracleopens in a new tab – Das optimistische Oracle von UMA ermöglicht es Smart Contracts, schnell jede Art von Daten für verschiedene Anwendungen zu empfangen, einschließlich Versicherungen, Finanzderivaten und Prognosemärkten.

Telloropens in a new tab – Tellor ist ein transparentes und erlaubnisfreies Oracle-Protokoll, mit dem Ihr Smart Contract problemlos alle Daten abrufen kann, wann immer er sie benötigt.

Band Protocolopens in a new tab – Band Protocol ist eine kettenübergreifende Daten-Oracle-Plattform, die reale Daten und APIs aggregiert und mit Smart Contracts verbindet.

Pyth Networkopens in a new tab – Das Pyth-Netzwerk ist ein First-Party-Finanz-Oracle-Netzwerk, das darauf ausgelegt ist, kontinuierlich Daten aus der realen Welt onchain in einer manipulationssicheren, dezentralen und autarken Umgebung zu veröffentlichen.

API3 DAOopens in a new tab – API3 DAO liefert First-Party-Oracle-Lösungen, die eine größere Quellentransparenz, Sicherheit und Skalierbarkeit in einer dezentralen Lösung für Smart Contracts bieten

Supraopens in a new tab – Ein vertikal integriertes Toolkit mit kettenübergreifenden Lösungen, das alle Blockchains, ob öffentlich (L1s und L2s) oder privat (Unternehmen), miteinander verbindet und dezentrale Oracle-Preis-Feeds bereitstellt, die für Onchain- und Offchain-Anwendungsfälle genutzt werden können.

Gas Networkopens in a new tab – Eine dezentrale Oracle-Plattform, die Echtzeit-Gaspreisdaten über die Blockchain hinweg bereitstellt. Indem es Daten von führenden Gaspreis-Datenanbietern onchain bereitstellt, trägt das Gas Network zur Förderung der Interoperabilität bei. Das Gas Network unterstützt Daten für über 35 Chains, einschließlich des Ethereum Mainnets und vieler führender L2s.

Weiterführende Lektüre

Artikel

Was ist ein Blockchain-Oracle?opens in a new tab – Chainlink
Was ist ein Blockchain-Oracle?opens in a new tab – Patrick Collins
Dezentrale Oracles: ein umfassender Überblickopens in a new tab – Julien Thevenard
Implementierung eines Blockchain-Oracles auf Ethereumopens in a new tab – Pedro Costa
Warum können Smart Contracts keine API-Aufrufe tätigen?opens in a new tab – StackExchange
Sie möchten also ein Preis-Oracle verwendenopens in a new tab – samczsun

Videos

Oracles und die Erweiterung des Nutzens der Blockchainopens in a new tab – Real Vision Finance

Tutorials

Wie man den aktuellen Preis von Ethereum in Solidity abruftopens in a new tab – Chainlink
Oracle-Daten konsumierenopens in a new tab – Chronicle

Beispielprojekte

Vollständiges Chainlink-Starterprojekt für Ethereum in Solidityopens in a new tab – HackBG