Wie funktionieren Oracle-Dienste unter der Haube?

Edmund Edgar von Reality Keys hier.

Was im Grunde passieren muss, ist, dass jemand sagt, welche Daten er möchte, der vertrauenswürdige Dienst eine ID bereitstellt, die ihn identifiziert (in unserem Fall ein Hash der Daten) und einen Schlüssel, mit dem er das Ergebnis signiert, und jemand eine Transaktion an ihn sendet der Vertrag. Dann warten wir auf das Ergebnis. Sobald das Ergebnis bekannt ist, signiert der vertrauenswürdige Dienst es mit seinem Schlüssel, jemand sendet eine weitere Transaktion mit den signierten Daten an den Vertrag, und der Vertrag tut, was passieren soll.

Dies kann entweder on-chain oder off-chain erfolgen. Wir tun dies Off-Chain, also stellen wir nur signierte Daten und einen Schlüssel bereit, und die Benutzer holen sich diese Daten von unserer Website und senden sie selbst an ihre Verträge. Dies wäre normalerweise Teil einer DApp, also beispielsweise PredictionTokenhaben einen Bildschirm, der eine Transaktion erstellt, um die ID von unserer Website abzurufen und einen Vertrag abzuschließen, und einen anderen Bildschirm, um die signierten Daten von unserer Website abzurufen und eine Transaktion zur Abwicklung des Vertrags zu senden. Oraclize erledigt dies on-chain, sodass Ihr Vertrag eine Anfrage an ihren Vertrag sendet und ihr Vertrag ein Ereignis in das Ereignisprotokoll schreibt und eine Kennung zurückgibt. Sie haben einen Prozess, der das Ereignisprotokoll überwacht, und wenn die Daten fertig sind, senden sie sie als signierte Transaktion an Ihren Vertrag, der den Absender des Vertrags überprüft (dies ist eine andere Möglichkeit, zu überprüfen, wer die Daten signiert hat) und tut, was auch immer es soll machen.

Aus Sicht eines Entwicklers besteht der Vorteil der On-Chain darin, dass Sie nur Anfragen an eine Stelle (die RPC-Schnittstelle Ihres Knotens) bearbeiten müssen und wenn Sie genau wissen, wann die Antwort fällig ist, muss Ihr Benutzer nur senden eine Transaktion statt einer, um den Vertrag einzurichten und eine andere, um das Ergebnis zu senden. Der Nachteil ist, dass es umständlich ist, richtig zu testen (Sie müssen entweder ihren Dienst nachahmen oder ein Live-Testnetz verwenden) und es gibt unangenehme Randfälle im Zusammenhang mit dem Gasverbrauch. (Es gibt einige Möglichkeiten, dies richtig zu machen, aber wenn Sie sich tatsächliche Verträge mit Oraclize ansehen, würden sie Oraclize oft erlauben, das gesamte Geld aus dem Vertragssaldo abzuziehen.)

Beachten Sie, dass Sie dem Dienst niemals vollständig vertrauen können (Oraclize hat einen kryptografischen Beweis, um ihre Behauptung zu untermauern, dass die abgerufenen Daten wirklich von der angegebenen Website stammen, aber der Vertrag kann dies nicht überprüfen, sodass dies nicht wirklich hilft). Möglicherweise möchten Sie, dass mehrere Dienste dasselbe tun, und der Vertrag mehrere Unterschriften erfordert. Dies ist auch etwas, das Sie in einem genehmigten Blockchain-Kontext tun möchten, in dem Sie bereits mehrere bekannte Teilnehmer haben, die Knoten ausführen und Blöcke signieren, sodass es sinnvoll wäre, sie dazu zu bringen, die Daten zu signieren.

Ich werde einen sehr groben Überblick geben, indem ich ein allgemeines Ziel, die Einschränkungen von Smart Contracts und die Umrisse einer Lösung beschreibe. Dies wird hoffentlich einen Kontext für die Implementierungsdetails liefern.

1) Das Ziel . Ein Smart Contract, der auf ein beobachtbares Ereignis oder einen Datenpunkt im Universum reagieren kann. Bei so vielen Daten, die im Internet herumschwappen, ist es selbstverständlich, automatisierte Reaktionen auf Ereignisse in Betracht zu ziehen. Dies ist außerhalb von Blockchains so verbreitet, dass es überraschend erscheinen kann, dass es innerhalb von Blockchains so schwierig ist.

2) Das Problem . Ein Smart Contract kann nicht nach Daten greifen, wie es ein typischer Webserver an eine API oder einen RSS-Feed (oder Bildschirmschoner usw.) anhängen könnte. Auf einer ziemlich tiefen Ebene gibt es hier ein echtes Problem, weil alles in einer Blockchain muss von allen Minern überprüfbar sein. Eine solche externe Beschaffung von Inputs wäre auch eine Quelle der Unsicherheit, die die Überprüfung verwirren würde. Alles in der Kette muss nicht nur von einem Server, sondern von ALLEN Servern verifiziert werden können, und nicht nur heute. Bis in alle Ewigkeit.

Wie würde irgendein Knoten in Jahren bestätigen, dass heute genau zu dieser Zeit eine bestimmte URL einen bestimmten Datenstrom erzeugt? Wenn es das nicht kann, wie würde es dann die Wahrheit der Daten in der Kette bestätigen? Wenn das nicht zuverlässig ist (ist es nicht), dann werden die Dinge auseinanderfallen. Wenn die Blockchain nicht nur anhand der Daten in der Blockchain selbst objektiv überprüfbar ist, funktioniert sie nicht.

3) Die Oracle-Lösung . Wir können uns eine vertraute Person vorstellen, die in den Dienst gedrängt wird (der arme Kerl). Er hat ein privilegiertes Konto, das Daten einspeisen kann, die er von außerhalb der Blockchain erhält, und er ist darauf angewiesen, die Blockchain in regelmäßigen Abständen zu aktualisieren. Angenommen, er schläft nie und aktualisiert die Tickerdaten alle paar Minuten.

Wir können uns eine vereinfachte Funktion wie folgt vorstellen:

function recordTickerData(bytes8 symbol, uint high, uint low, uint close) 
  onlyOracle 
  returns(bool success) 
{
  // store the data
  // possibly react to the data
  return true;
}

Groß. Nur das Orakel darf Daten auf diese Weise einspeisen, aber sobald die Daten eingespeist sind, können wir anfangen, Dinge damit zu tun, was wir wollen.

Die Miner können die Blockchain verifizieren. Sie können nicht bestätigen, dass die Eingaben des Orakels mit irgendetwas im äußeren Universum übereinstimmen, aber sie können bestätigen, dass die Eingaben des Orakels zulässig sind und alle daraus resultierenden Transaktionen legitim sind.

Wir haben einige lose Enden zu lösen. Erstens muss das Orakel schlafen, und dies ist eindeutig eine Aufgabe für etwas Automatisiertes. Zweitens muss das Orakel jedes Mal, wenn es diese Funktion ausführt, Gas für die Transaktion zahlen. Das bedeutet, dass wir zuerst das Orakel bezahlen müssen, damit es etwas Geld hat, um das Gas zu bezahlen.

Sehen Sie, wohin das führt?

Ohne auf Implementierungsdetails einzugehen, muss das Oracle die eingehenden Daten aus einer Quelle auflösen und sie der Schnittstelle des Vertrags zuordnen. Es werden Details darüber angegeben, wie oft die Funktion aufgerufen werden soll usw. Und es wird die administrative Frage der Finanzierung geben, da das Orakel eine kontinuierliche Finanzierungsquelle benötigen wird, um das Gas für seine regelmäßigen Dateninjektionen zu bezahlen. Jeder mit ernsthafter Finanzierung wird überprüfen wollen, ob das Oracle-Arrangement vertrauenswürdig ist, da seine Eingaben nicht triviale Konsequenzen haben werden. Wir müssen also eine Datenquelle auswählen, die allgemein akzeptiert wird. Wir haben einige grobe Umrisse verallgemeinerter Oracle-Lösungen – lassen Sie uns einen vertrauenswürdigen externen Dienst haben, der externe Daten einer unserer Eingabefunktionen zuordnet und regelmäßig Aktualisierungstransaktionen sendet.

Meinungsmärkte wie Auger und Gnosis präsentieren Informationen aus der Außenwelt etwas anders. Angenommen, Ihr Vertrag hängt von einer einmaligen Wahr/Falsch-Bedingung ab, und es ist nicht offensichtlich, dass es eine externe Quelle gibt, von der Sie im Voraus wissen können, die Ihrem Vertrag eine einfache Wahrheit übermittelt.

Wird Trump zum Beispiel die Wahl 2017 gewinnen?

Meinungsmärkte bieten eine Möglichkeit, die Frage zu stellen und im Wesentlichen die Ermittlung der Wahrheit an eine menschliche Gemeinschaft auszulagern. Es handelt sich um einen Wettmarkt, der die Frage letztendlich so regelt, wie Sie es im Voraus konfigurieren können.

Im Pseudo-Code kann Ihr Vertrag Folgendes berücksichtigen:

if(AugurQuestion(123).isDecided and isTrue) then ... do stuff.

Ich hoffe, dass das Vorangegangene etwas die Bühne bereitet und einen Kontext zu den Implementierungsdetails dieser Bemühungen liefert.

Sie haben selbst einen Vertrag, der mit der realen Welt verbunden ist.

1. Sie registrieren sich mit ihrem Vertrag und definieren eine Funktion, die sie aufrufen sollen
2. Ihr Vertrag wird von einer externen Entität gelesen, die Ihre "Anfrage" sieht
3. die externe Entität führt die Abfrage aus (z. B. Aufruf von random.org)
4. ruft Ihre Callback-Funktion entweder direkt oder über ihren Vertrag auf
5. Gewinn ;-)

Die einfachste Erklärung, wie Orakel funktionieren, wäre ein Blick auf den Chainlink Runlog Initiator .

1. Es wird ein Oracle-Vertrag bereitgestellt, der angibt, dass es sich um einen Oracle-Dienst handelt. Dies ist ein On-Chain-Vertrag.
2. Ein Off-Chain-Service wird bereitgestellt. Dies wird in der ETH-Kette nicht sichtbar sein, aber es wird mit einer ETH-Wallet verbunden. Dies kann so etwas wie ein VM- oder Docker-Job sein , der API-Aufrufe durchführen kann.
3. Diese VM/Off-Chain-Infrastruktur wird die ETH-Kette auf Transaktionen „überwachen“, die Daten enthalten, die sie identifizieren. Das „Orakel“ wird eine Kombination aus diesem On-Chain-Vertrag und diesem Off-Chain-Service sein.
4. Ein weiterer Smart Contract erstellt eine Transaktion, die die spezifizierende ID dieses Orakels aufruft und beispielsweise Off-Chain-Daten über eine API anfordert.
5. Unser Orakel sieht diese Transaktion und erstellt den API-Aufruf außerhalb der Kette. Wenn die Daten vom API-Aufruf zurückgegeben werden, erstellt das Orakel mit diesen Daten eine neue Transaktion in der Kette.
6. Der Smart Contract, der die Daten ursprünglich angefordert hat, zieht nun Daten aus dieser neuen Transaktion.

Das ist es in einer sehr einfachen Nussschale. Sie werden feststellen, dass Sie Gas brauchen:

1. Für Transaktionen (ETH)
2. Für Orakel (LINK oder andere Krypto)