CHAINLINK EIN DEZENTRALES ORACLE-NETZWERK - TRANSLATEWHITEPAPER

Die Seite wird erstellt Vanessa Janßen

Finanzen

Deutsch

Like
Teilen
Einbetten
Vollbild
Folien
HTML Herunterladen
PDF Herunterladen
Missbrauch

←

WEITER LESEN

→

Transkription von Seiteninhalten

Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten

ChainLink
Ein dezentrales Oracle-Netzwerk

Steve Ellis, Ari Juels †, und Sergey Nazarov

4. September 2017 ( v1.0)

Abstrakt

Intelligente Verträge stehen kurz davor, viele Branchen zu revolutionieren, indem sie die
Notwendigkeit traditioneller rechtlicher Vereinbarungen und zentral automatisierter digitaler
Vereinbarungen ersetzen. Sowohl die Leistungsüberprüfung als auch die Ausführung beruhen auf
manuellen Aktionen einer der Vertragsparteien oder auf einem automatisierten System, das
relevante Änderungen programmgesteuert abruft und aktualisiert. Leider können die Blockchains,
auf denen Smart Contracts ausgeführt werden, aufgrund ihrer zugrunde liegenden
Konsensprotokolle die native Kommunikation mit externen Systemen nicht unterstützen.
Heute besteht die Lösung für dieses Problem darin, eine neue Funktionalität einzuführen,
die als Orakel, das bietet Konnektivität zur Außenwelt. Bestehende Orakel sind zentralisierte
Dienste. Jeder intelligente Vertrag, der solche Dienste nutzt, weist eine einzige Fehlerquelle
auf, sodass er nicht sicherer ist als eine herkömmliche, zentral ausgeführte digitale
Vereinbarung.
In diesem Artikel stellen wir ChainLink vor, ein dezentrales Orakelnetzwerk. Wir beschreiben
die On-Chain-Komponenten, die ChainLink für Verträge zur Erlangung externer Konnektivität
bereitstellt, und die Software, die die Knoten des Netzwerks mit Strom versorgt. Wir präsentieren
sowohl ein einfaches On-Chain-System zur Aggregation von Vertragsdaten als auch einen
effizienteren Konsensmechanismus außerhalb der Kette. Wir beschreiben auch die Unterstützung
von Reputations- und Sicherheitsüberwachungsdiensten für ChainLink, die Benutzern helfen,
fundierte Anbieterauswahlen zu treffen und selbst unter aggressiv widrigen Bedingungen einen
robusten Dienst zu erzielen. Schließlich charakterisieren wir die Eigenschaften eines idealen Orakels
als Leitfaden für unsere Sicherheitsstrategie und legen mögliche zukünftige Verbesserungen fest,
einschließlich umfangreicher Orakelprogrammierung, Änderungen der Datenquelleninfrastruktur
und vertraulicher Ausführung intelligenter Verträge.

Inhalt
1. Einleitung                                                                                3

2 Architekturübersicht                                                                       4
   2.1 On-Chain-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . .               5
   2.2 O ﬀ -Kettenarchitektur. . . . . . . . . . . . . . . . . . . . . . . . . .             6

3 Oracle-Sicherheit                                                                          7

4 ChainLink-Dezentralisierungsansatz                                                        11
   4.1 Quellen verteilen. . . . . . . . . . . . . . . . . . . . . . . . . . . .             11
   4.2 Orakel verteilen. . . . . . . . . . . . . . . . . . . . . . . . . . . .              11

5 ChainLink-Sicherheitsdienste                                                              16
   5.1 Validierungssystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . .          16
   5.2 Reputationssystem. . . . . . . . . . . . . . . . . . . . . . . . . . . .             17
   5.3 Zertifizierungsservice. . . . . . . . . . . . . . . . . . . . . . . . . . .          19
   5.4 Vertrags-Upgrade-Service. . . . . . . . . . . . . . . . . . . . . . . .              20
   5.5 Verwendung von LINK-Token. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   21

6 Langfristige technische Strategie                                                         21
    6.1 Vertraulichkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          21
    6.2 Änderungen der Infrastruktur. . . . . . . . . . . . . . . . . . . . . . . . . .     25
    6.3 Berechnung der O ﬀ -Kette. . . . . . . . . . . . . . . . . . . . . . . . . .        26

7 Bestehende Oracle-Lösungen                                                                26

8 Fazit                                                                                     27

Eine O ﬀ -Kettenaggregation                                                                 33
   A.1 OCA Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          34
   A.2 Beweisskizzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .           36
   A.3 Diskussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          37

B SGX-Vertrauensannahmen                                                                    38

                                                               2

1. Einleitung
Intelligente Verträge sind Anwendungen, die auf einer dezentralen Infrastruktur wie einer Blockchain
ausgeführt werden. Sie sind manipulationssicher in dem Sinne, dass keine Partei (auch nicht ihr
Schöpfer) ihren Code ändern oder ihre Ausführung stören kann. In der Vergangenheit wurden in Code
enthaltene Verträge zentral ausgeführt, sodass sie von einer privilegierten Partei geändert, gekündigt
und sogar gelöscht werden können. Im Gegensatz dazu schaffen die Ausführungsgarantien von Smart
Contracts, die alle Parteien an eine schriftliche Vereinbarung binden, eine neue und leistungsstarke
Art von Vertrauensbeziehung, die nicht auf dem Vertrauen in eine Partei beruht. Intelligente Verträge
sind daher ein überlegenes Mittel zur Realisierung und Verwaltung digitaler Vereinbarungen, da sie
sich selbst überprüfen und selbst ausführen (dh wie oben erläutert manipulationssicher sind).

Das leistungsstarke neue Vertrauensmodell, das intelligente Verträge verkörpern, bringt jedoch eine
neue technische Herausforderung mit sich: Konnektivität. Die überwiegende Mehrheit der interessanten
[27] 1 Intelligente Vertragsanwendungen basieren auf Daten über die reale Welt, die aus Schlüsselressourcen
stammen, insbesondere Datenfeeds und APIs, die außerhalb der Blockchain liegen. Aufgrund der
Mechanismen der Konsensmechanismen, die Blockchains zugrunde liegen, kann eine Blockchain solche
kritischen Daten nicht direkt abrufen.
Wir schlagen eine Lösung für das Problem der intelligenten Vertragskonnektivität in Form von ChainLink
vor, einem sicheren Orakel-Netzwerk. Was ChainLink von anderen Oracle-Lösungen unterscheidet, ist seine
Fähigkeit, als vollständig dezentrales Netzwerk zu arbeiten. Dieser dezentrale Ansatz schränkt das Vertrauen
in eine einzelne Partei ein und ermöglicht es, die in intelligenten Verträgen geschätzte manipulationssichere
Qualität auf den End-to-End-Betrieb zwischen intelligenten Verträgen und den APIs auszudehnen, auf die sie
sich verlassen. Es ist notwendig, intelligente Verträge extern bekannt zu machen, dh in der Lage zu sein, mit
Ressourcen der Kette zu interagieren, wenn sie die heute verwendeten digitalen Vereinbarungen ersetzen
sollen.
Heutzutage verwendet der Löwenanteil der digitalen Vertragsvereinbarungen, die digital
automatisiert wurden, externe Daten, um die vertragliche Leistung nachzuweisen, und erfordert, dass
Datenausgaben an externe Systeme übertragen werden. Wenn intelligente Verträge diese älteren
vertraglichen Mechanismen ersetzen, erfordern sie hochsichere Versionen derselben Arten von
Dateneingaben und -ausgaben. Beispiele für potenzielle Smart Contracts der nächsten Generation und
deren Datenanforderungen sind:

• • Wertpapiere intelligente Verträge B. Anleihen, Zinsderivate und viele andere
erfordern den Zugriff auf APIs, die Marktpreise und Marktreferenzdaten, z. B.
Zinssätze, melden.
1 Die Hauptanwendung von intelligenten Verträgen in Ethereum ist heute die Verwaltung von Token, die in den meisten
intelligenten Vertragsnetzwerken eine gängige Funktionalität sind. Wir glauben, dass der derzeitige Fokus auf Token unter
Ausschluss vieler anderer möglicher Anwendungen auf einen Mangel an angemessenen Orakel-Diensten zurückzuführen ist, eine
Situation, die ChainLink speziell beheben möchte.

• • Intelligente Versicherungsverträge Sie benötigen Daten-Feeds zu IoT-Daten im Zusammenhang mit dem
       betreffenden versicherbaren Ereignis, z. B.: War die magnetische Tür des Lagers zum Zeitpunkt des
       Verstoßes verschlossen, war die Brandmauer des Unternehmens online oder war der Flug, für den Sie eine
       Versicherung hatten, pünktlich.

    • • Intelligente Handelsfinanzierungsverträge benötigen GPS-Daten über Sendungen, Daten
       aus ERP-Systemen der Lieferkette und Zolldaten über die versendeten Waren, um die
       Erfüllung vertraglicher Verpflichtungen zu bestätigen.

    Ein weiteres Problem, das diesen Beispielen gemeinsam ist, ist die Unfähigkeit intelligenter Verträge,
Daten in Off-Chain-Systeme auszugeben. Diese Ausgabe erfolgt häufig in Form einer Zahlungsnachricht, die
an eine herkömmliche zentralisierte Infrastruktur weitergeleitet wird, in der Benutzer bereits Konten haben,
z. B. für Bankzahlungen, PayPal und andere Zahlungsnetzwerke. Die Fähigkeit von ChainLink, Daten im
Auftrag eines intelligenten Vertrags sicher an APIs und verschiedene Legacy-Systeme zu übertragen,
ermöglicht die Erstellung von extern bekannten manipulationssicheren Verträgen.

Whitepaper-Roadmap
In diesem Whitepaper * überprüfen wir die ChainLink-Architektur (Abschnitt 2). Anschließend erklären
wir, wie wir die Sicherheit für Orakel definieren (Abschnitt 3). Wir beschreiben den ChainLink-Ansatz
zur Dezentralisierung / Verteilung von Orakeln und Datenquellen (Abschnitt 4) und diskutieren
anschließend die vier von ChainLink vorgeschlagenen Sicherheitsdienste sowie die Rolle von
LINK-Token (Abschnitt 5). Anschließend beschreiben wir eine vorgeschlagene langfristige
Entwicklungsstrategie, die einen besseren Schutz der Vertraulichkeit, die Verwendung
vertrauenswürdiger Hardware, Änderungen der Infrastruktur und die allgemeine Programmierbarkeit
von Oracle umfasst (Abschnitt 6). Wir überprüfen kurz alternative Orakelentwürfe (Abschnitt 7) und
schließen mit einer kurzen Diskussion der Entwurfsprinzipien und der Philosophie, die die Entwicklung
von ChainLink leiten (Abschnitt 8).

2 Architekturübersicht
Das Hauptfunktionsziel von ChainLink besteht darin, zwei Umgebungen zu verbinden: On-Chain und O-Chain. Im
Folgenden wird die Architektur jeder ChainLink-Komponente beschrieben. ChainLink wird zunächst auf Ethereum
[16] [35] aufbauen, beabsichtigt jedoch, alle führenden intelligenten Vertragsnetzwerke sowohl für
kettenübergreifende als auch für kettenübergreifende Interaktionen zu unterstützen. ChainLink wurde sowohl in
der On- als auch in der Off-Chain-Version unter Berücksichtigung der Modularität entwickelt. Jedes Teil des
ChainLink-Systems kann aktualisiert werden, sodass verschiedene Komponenten ausgetauscht werden können,
wenn bessere Techniken und konkurrierende Implementierungen entstehen.

                                                        4

2.1 On-Chain-Architektur
Als Oracle-Dienst geben ChainLink-Knoten Antworten auf Daten zurück Anfragen oder Anfragen hergestellt
durch oder im Auftrag eines Benutzervertrags, den wir als bezeichnen Verträge anfordern und bezeichnen
mit USER-SC. Die On-Chain-Schnittstelle von ChainLink zum Anfordern von Verträgen ist selbst ein
On-Chain-Vertrag, den wir bezeichnen CHAINLINK-SC.
Hinter CHAINLINK-SC, ChainLink verfügt über eine On-Chain-Komponente, die aus drei
Hauptverträgen besteht: a Reputationsvertrag, ein Auftragsabgleichsvertrag, und ein Aggregatvertrag.
Der Reputationsvertrag verfolgt die Leistungsmetriken von Oracle-Service-Providern. Der
Auftragsabgleich-Smart-Vertrag nimmt eine vorgeschlagene Service-Level-Vereinbarung entgegen,
protokolliert die SLA-Parameter und sammelt Gebote von Oracle-Anbietern. Anschließend werden
Gebote mithilfe des Reputationsvertrags ausgewählt und die Orakel-SLA abgeschlossen. Der
Aggregatvertrag sammelt die Antworten der Orakelanbieter und berechnet das endgültige kollektive
Ergebnis der ChainLink-Abfrage. Außerdem werden die Metriken von Oracle-Anbietern in den
Reputationsvertrag zurückgeführt. ChainLink-Verträge sind modular aufgebaut, sodass sie bei Bedarf
von Benutzern konfiguriert oder ersetzt werden können. Der On-Chain-Workflow besteht aus drei
Schritten: 1) Orakelauswahl, 2) Datenberichterstattung, 3) Ergebnisaggregation.

Oracle-Auswahl Ein Käufer von Oracle Services legt Anforderungen fest, aus denen sich ein
Vorschlag für ein Service Level Agreement (SLA) zusammensetzt. Der SLA-Vorschlag enthält
Details wie Abfrageparameter und die Anzahl der vom Käufer benötigten Orakel. Darüber hinaus
gibt der Käufer den Ruf und die aggregierten Verträge an, die für den Rest der Vereinbarung
verwendet werden sollen.
Mithilfe der in der Kette gepflegten Reputation und eines robusteren Datensatzes aus Protokollen
früherer Verträge können Käufer Orakel manuell über Off-Chain-Listing-Services sortieren, filtern und
auswählen. Wir beabsichtigen, dass ChainLink einen solchen Auflistungsservice unterhält, alle
ChainLink-bezogenen Protokolle sammelt und die Binärdateien der aufgelisteten Orakelverträge
überprüft. In Abschnitt 5 werden die Listingservice- und Reputationssysteme näher erläutert. Die
Daten, die zum Generieren von Listings verwendet werden, werden aus der Blockchain abgerufen,
sodass alternative Orakel-Listing-Services erstellt werden können. Käufer werden SLA-Vorschläge bei
Orakel der Kette einreichen und eine Einigung erzielen, bevor sie die SLA in der Kette abschließen.

Manueller Abgleich ist nicht in allen Situationen möglich. Beispielsweise muss ein Vertrag
möglicherweise Oracle-Dienste dynamisch als Reaktion auf seine Auslastung anfordern. Automatisierte
Lösungen lösen dieses Problem und verbessern die Benutzerfreundlichkeit. Aus diesen Gründen wird von
ChainLink auch ein automatisierter Orakelabgleich durch die Verwendung von Auftragsabgleichsverträgen
vorgeschlagen.
Sobald der Käufer seinen SLA-Vorschlag spezifiziert hat, anstatt die Orakel direkt zu kontaktieren,
wird er die SLA einem Auftragsabgleichsvertrag unterziehen. Die Übermittlung des Vorschlags an den
Auftragsabgleichsvertrag löst ein Protokoll aus, das Orakelanbieter erstellen können

überwachen und filtern basierend auf ihren Fähigkeiten und Servicezielen. ChainLink-Knoten
entscheiden dann, ob sie auf den Vorschlag bieten möchten oder nicht, wobei der Vertrag nur Gebote
von Knoten akzeptiert, die den Anforderungen des SLA entsprechen. Wenn ein Orakel-Dienstleister auf
einen Vertrag bietet, verpflichtet er sich dazu, insbesondere indem er den Strafbetrag anfügt, der
aufgrund seines Fehlverhaltens verloren gehen würde, wie in der SLA definiert.
Gebote werden für das gesamte Gebotsfenster angenommen. Sobald die SLA genügend qualifizierte
Gebote erhalten hat und das Gebotsfenster beendet ist, wird die angeforderte Anzahl von Orakeln aus dem
Gebotspool ausgewählt. Strafzahlungen, die während des Bietungsprozesses angeboten wurden, werden an
Orakel zurückgegeben, die nicht ausgewählt wurden, und ein endgültiger SLA-Datensatz wird erstellt. Wenn
das abgeschlossene SLA aufgezeichnet wird, wird ein Protokoll ausgelöst, das die ausgewählten Orakel
benachrichtigt. Die Orakel führen dann die von der SLA festgelegte Aufgabe aus.

Datenberichterstattung Sobald der neue Orakel-Datensatz erstellt wurde, führen die Orakel der Kette die
Vereinbarung aus und melden sie in der Kette zurück. Weitere Einzelheiten zu Wechselwirkungen zwischen Ketten
finden Sie in den Abschnitten 2.2 und 4.

Ergebnisaggregation Sobald die Orakel ihre Ergebnisse dem Orakelvertrag mitgeteilt haben,
werden ihre Ergebnisse dem Aggregatvertrag zugeführt. Der Aggregatvertrag bewertet die
kollektiven Ergebnisse und berechnet eine gewichtete Antwort. Die Gültigkeit jeder
Orakelantwort wird dann dem Reputationsvertrag gemeldet. Schließlich wird die gewichtete
Antwort an die angegebene Vertragsfunktion in zurückgegeben USER-SC.
Das Erkennen von abweichenden oder falschen Werten ist ein Problem, das für jeden Typ von
Datenfeed und Anwendung spezifisch ist. Beispielsweise kann es für numerische Daten erforderlich sein,
abweichende Antworten vor der Mittelwertbildung zu erkennen und abzulehnen, jedoch nicht für boolesche
Daten. Aus diesem Grund gibt es keinen bestimmten Aggregatvertrag, sondern eine konfigurierbare
Vertragsadresse, die vom Käufer angegeben wird. ChainLink wird einen Standardsatz von
Aggregatverträgen enthalten, es können jedoch auch benutzerdefinierte Verträge angegeben werden,
sofern diese der Standardberechnungsschnittstelle entsprechen.

2.2 O ﬀ -Kettenarchitektur
In der Kette besteht ChainLink zunächst aus einem Netzwerk von Orakelknoten, die mit dem Ethereum-Netzwerk
verbunden sind, und wir beabsichtigen, alle führenden Smart-Contract-Netzwerke zu unterstützen. Diese Knoten sammeln
unabhängig voneinander Antworten auf Anfragen der Kette. Wie wir weiter unten erläutern, werden ihre einzelnen
Antworten über einen von mehreren möglichen Konsensmechanismen zu einer globalen Antwort zusammengefasst, die
an einen anfordernden Vertrag zurückgegeben wird USER-SC. Die ChainLink-Knoten werden von der
Standard-Open-Source-Kernimplementierung unterstützt, die Standard-Blockchain-Interaktionen, die Planung und die
Verbindung mit gemeinsamen externen Ressourcen verwaltet. Knotenbetreiber können Software hinzufügen

Erweiterungen, sogenannte externe Adapter, ermöglichen es den Betreibern, zusätzliche spezialisierte
Off-Chain-Services anzubieten. ChainLink-Knoten wurden bereits neben öffentlichen Blockchains und
privaten Netzwerken in Unternehmenseinstellungen bereitgestellt. Die dezentrale Ausführung der Knoten
ist die Motivation für das ChainLink-Netzwerk.

ChainLink Core. Die Kernknotensoftware ist für die Anbindung an die Blockchain, die Planung und den Ausgleich
der Arbeit zwischen den verschiedenen externen Diensten verantwortlich. Von ChainLink-Knoten ausgeführte
Arbeiten werden wie folgt formatiert Zuordnungen. Jede Zuweisung besteht aus einer Reihe kleinerer
Auftragsspezifikationen, die als Unteraufgaben bezeichnet werden und als Pipeline verarbeitet werden. Jede
Unteraufgabe hat eine bestimmte Operation, die sie ausführt, bevor sie ihr Ergebnis an die nächste Unteraufgabe
weitergibt und schließlich ein endgültiges Ergebnis erzielt. In der Knotensoftware von ChainLink sind einige
Unteraufgaben integriert, darunter HTTP-Anforderungen, JSON-Analyse und Konvertierung in verschiedene
Blockchain-Formate.

Externe Adapter. Über die integrierten Unteraufgabentypen hinaus können benutzerdefinierte
Unteraufgaben durch Erstellen definiert werden Adapter. Adapter sind externe Services mit einer minimalen
REST-API. Durch die serviceorientierte Modellierung von Adaptern können Programme in jeder
Programmiersprache einfach implementiert werden, indem einfach eine kleine Zwischen-API vor dem
Programm hinzugefügt wird. Ebenso kann die Interaktion mit komplizierten mehrstufigen APIs auf einzelne
Unteraufgaben mit Parametern vereinfacht werden.

Unteraufgabenschemata. Wir gehen davon aus, dass viele Adapter Open Source sind, damit die Dienste von
verschiedenen Community-Mitgliedern geprüft und ausgeführt werden können. Da viele verschiedene
Adaptertypen von vielen verschiedenen Entwicklern entwickelt werden, ist die Gewährleistung der Kompatibilität
zwischen Adaptern von entscheidender Bedeutung.
ChainLink arbeitet derzeit mit einem Schemasystem, das auf dem JSON-Schema [36] basiert, um
anzugeben, welche Eingaben jeder Adapter benötigt und wie sie formatiert werden sollen. In ähnlicher
Weise geben Adapter ein Ausgabeschema an, um das Format der Ausgabe jeder Unteraufgabe zu
beschreiben.

3 Oracle-Sicherheit
Um die Sicherheitsarchitektur von ChainLink zu erklären, müssen wir zunächst erklären, warum
Sicherheit wichtig ist - und was sie bedeutet.

Warum müssen Orakel sicher sein? Zurück zu unseren einfachen Beispielen in Abschnitt 1: Wenn eine
intelligente Vertragssicherheit einen falschen Datenfeed erhält, kann sie die falsche Partei auszahlen, wenn
intelligente Vertragsversicherungsdatenfeeds vom Versicherten manipuliert werden können

Abbildung 1: ChainLink-Workflow: 1) USER-SC macht eine On-Chain-Anfrage; 2) CHAINLINK-SC
protokolliert ein Ereignis für die Orakel; 3) Der ChainLink-Kern nimmt das Ereignis auf und leitet die
Zuweisung an einen Adapter weiter. 4) Der ChainLink-Adapter führt eine Anforderung an eine externe API
aus. 5) Der ChainLink-Adapter verarbeitet die Antwort und gibt sie an den Kern zurück. 6) Der
ChainLink-Kern meldet die Daten an CHAINLINK-SC; 7) CHAINLINK-SC aggregiert Antworten und gibt sie als
einzelne Antwort an zurück USER-SC.

Es kann zu Versicherungsbetrug kommen, und wenn GPS-Daten, die einem Handelsfinanzierungsvertrag zugewiesen wurden, nach

dem Verlassen des Datenanbieters geändert werden können, kann die Zahlung für Waren freigegeben werden, die noch nicht

angekommen sind.

Im Allgemeinen bietet eine gut funktionierende Blockchain mit ihrer Hauptbuch- oder
Bulletin-Board-Abstraktion sehr starke Sicherheitseigenschaften. Benutzer verlassen sich auf die Blockchain
als eine Funktion, die Transaktionen korrekt validiert und verhindert, dass Daten geändert werden. Sie
behandeln es effektiv wie einen vertrauenswürdigen Dritten (ein Konzept, das wir weiter unten ausführlich
diskutieren). Ein unterstützender Orakeldienst muss ein Sicherheitsniveau bieten, das dem der von ihm
unterstützten Blockchain entspricht. Daher muss auch ein Orakel den Benutzern als wirksamer
vertrauenswürdiger Dritter dienen und mit sehr hoher Wahrscheinlichkeit korrekte und zeitnahe Antworten
liefern. Die Sicherheit eines Systems ist nur so stark wie das schwächste Glied. Daher ist ein äußerst
vertrauenswürdiges Orakel erforderlich, um die Vertrauenswürdigkeit einer hochentwickelten Blockchain zu
gewährleisten.

Orakelsicherheit definieren: Eine ideale Ansicht. Um über die Sicherheit von Orakeln nachzudenken, müssen wir sie
zuerst definieren. Ein lehrreicher, prinzipieller Weg, über Orakelsicherheit nachzudenken, ergibt sich aus dem
folgenden Gedankenexperiment. Stellen Sie sich vor, ein vertrauenswürdiger Dritter (Trusted Third Party, TTP) -
eine ideale Entität oder Funktionalität, die Anweisungen stets genau nach dem Buchstaben ausführt - wurde
beauftragt, ein Orakel auszuführen. Wir werden dieses Orakel mit bezeichnen ORACLE ( Verwenden Sie im
Allgemeinen alle Großbuchstaben, um eine Entität zu kennzeichnen, der von den Benutzern vollständig vertraut
wird. Nehmen Sie an, dass der TTP Daten aus einer absolut vertrauenswürdigen Datenquelle bezieht Src .
Angesichts dieses magischen Dienstes ORAKEL, Welche Anweisungen würden wir von ihm verlangen?
Um die Eigenschaft der Integrität zu erreichen, die auch als Authentizitätseigenschaft bezeichnet wird
[24], würden wir dies einfach verlangen ORAKEL Führen Sie die folgenden Schritte aus:

Figur 2: Verhalten eines idealen Orakels ORAKEL wird durch folgende Schritte definiert: 1) Anfrage annehmen; 2)
Daten erhalten; 3) Daten zurückgeben. Um die Vertraulichkeit einer Anforderung beim Entschlüsseln zu schützen, ORAKEL
Verwendet oder enthüllt niemals die darin enthaltenen Daten, außer zum Abfragen Src .

1. Anfrage annehmen: Aufnahme aus einem intelligenten Vertrag USER-SC eine Anfrage Req = ( Src , τ, q)
das gibt eine Zieldatenquelle an Src , eine Zeit oder einen Bereich von Zeiten τ, und eine Abfrage
q;

2. Daten erhalten: Anfrage senden q zu Src zum Zeitpunkt τ;

3. Daten zurückgeben: Nach Erhalt der Antwort ein, Rückkehr ein zum intelligenten Vertrag.

Diese einfachen Anweisungen, die korrekt ausgeführt werden, definieren einen starken, aussagekräftigen,
aber einfachen Begriff von Sicherheit. Intuitiv diktieren sie das ORAKEL fungiert als vertrauenswürdig
Brücke zwischen Src und USER-SC. 2 Zum Beispiel wenn Src ist https://www.FountOfKnowledge.com,
τ ist 16 Uhr und q = „ Preis für Ticker INTC ”, Die Integrität von ORAKEL garantiert, dass es zur
Verfügung stellen wird USER-SC mit genau dem Preis von INTC, der um 16 Uhr unter
https://www.FountOfKnowledge.com abgefragt wurde.
Vertraulichkeit ist eine weitere wünschenswerte Eigenschaft für Orakel. Wie USER-SC sendet Anf
zu ORAKEL im klaren auf der Blockchain, Anf ist Öffentlichkeit. Es gibt viele Situationen, in denen Anf ist
empfindlich und seine Veröffentlichung könnte schädlich sein. Wenn USER-SC ist zum Beispiel ein
Flugversicherungsvertrag und sendet ORAKEL eine Anfrage Anf in Bezug auf den Flug eines
bestimmten Benutzers ( q = „ Ätherluftflug 338 ”) Wäre das Ergebnis, dass die Flugpläne eines Benutzers
der ganzen Welt offenbart werden. Wenn USER-SC ist ein Vertrag für
2 Natürlich werden hier viele Details weggelassen. ORAKEL sollte mit beiden kommunizieren USER-SC
und Quelle Src über sichere, dh manipulationssichere Kanäle. (Wenn Src ist ein Webserver, TLS ist erforderlich.
Kommunizieren mit USER-SC, ORACLE muss sicher sein, die richtige Blockchain abzukratzen und digital zu signieren
EIN passend.)

Finanzhandel, Anf könnte Informationen über die Trades und das Portfolio eines Benutzers verlieren.
Es gibt natürlich noch viele andere Beispiele.
Zum Schutz der Vertraulichkeit von Req, Wir können diese Daten in verlangen Anf unter einem
(öffentlichen Schlüssel) verschlüsselt werden, der zu gehört ORAKEL. Weitere Nutzung der TTP-Natur von ORAKEL,
wir könnten dann einfach geben ORAKEL die Informationsflussbeschränkung:

Beim Entschlüsseln Req, offenbaren oder verwenden Sie niemals Daten in Anf außer zu fragen Src .

Es gibt andere wichtige Orakeleigenschaften, wie die Verfügbarkeit, die letzte der
klassischen CIA-Triade (Vertraulichkeit-Integrität-Verfügbarkeit). Ein wirklich idealer Service ORAKEL,
würde natürlich nie untergehen. Die Verfügbarkeit umfasst auch subtilere Eigenschaften
wie Zensurresistenz: Eine ehrliche ORAKEL wird bestimmte intelligente Verträge nicht
herausgreifen und ihre Anfragen ablehnen.
Das Konzept eines vertrauenswürdigen Dritten ähnelt der Vorstellung einer idealen Funktionalität [7],
mit der die Sicherheit kryptografischer Protokolle in bestimmten Modellen nachgewiesen werden kann. Wir
können eine Blockchain auch in ähnlichen Begriffen modellieren und sie als TTP konzipieren, das ein ideales
Bulletin Board beibehält. Seine Anweisungen lauten, Transaktionen zu akzeptieren, zu validieren, zu
serialisieren und dauerhaft im Bulletin Board zu verwalten, einer Datenstruktur, die nur zum Anhängen
geeignet ist.

Warum das ideale Orakel ( ORAKEL) ist schwer zu erreichen. Es gibt natürlich keine absolut
vertrauenswürdige Datenquelle Src . Daten können aufgrund fehlerhafter Websites, betrügerischer
Dienstleister oder ehrlicher Fehler harmlos oder böswillig beschädigt werden.
Wenn Src ist nicht vertrauenswürdig, auch wenn ORAKEL funktioniert genau wie ein TTP, wie oben beschrieben,
entspricht jedoch nicht vollständig dem von uns gewünschten Sicherheitsbegriff. Bei einer fehlerhaften Quelle Src , Die oben
definierte Integritätseigenschaft bedeutet nicht mehr die Antwort eines Orakels ein ist richtig. Wenn der wahre Preis von
Intel 40 US-Dollar beträgt und https://www.FountOfKnowledge.com
Dann wird es beispielsweise als $ 50 falsch gemeldet ORAKEL sendet den falschen Wert a = $ 50 bis USER-SC. Dieses
Problem ist bei Verwendung einer einzelnen Quelle unvermeidbar Src . ORAKEL
hat einfach keine Möglichkeit zu wissen, ob die Antworten Src bietet zu seinen Abfragen sind korrekt.
Ein größeres Problem ist natürlich die Tatsache, dass unser TTP für ORAKEL ist nur eine Abstraktion. Kein Dienstleister
ist bedingungslos vertrauenswürdig. Selbst die Besten können fehlerhaft oder gehackt sein. Es gibt also keine Möglichkeit
für einen Benutzer oder einen intelligenten Vertrag, die absolute Sicherheit eines Dienstes zu haben ORAKEL wird seine
Anweisungen treu ausführen.
ChainLink begründet seine Sicherheitsprotokolle mit dieser idealen Funktionalität
ORAKEL. Unser Ziel bei ChainLink ist es, ein reales System mit zu erreichen Eigenschaften so nah
wie möglich an denen von ORAKEL unter realistischen Vertrauensannahmen. Wir erklären jetzt
wie.
Der Einfachheit halber bezeichnen wir nun mit CHAINLINK-SC Der gesamte Satz von
ChainLink-Verträgen, dh die vollständige On-Chain-Funktionalität (nicht nur die Benutzeroberfläche)

Verträge anfordern). Wir abstrahieren dabei die mehreren Einzelverträge, die tatsächlich in der
Systemarchitektur verwendet werden.

4 ChainLink-Dezentralisierungsansatz
Wir schlagen drei grundlegende komplementäre Ansätze vor, um fehlerhafte Knoten zu vermeiden: (1)
Verteilung von Datenquellen; (2) Verteilung von Orakeln; und (3) Verwendung vertrauenswürdiger
Hardware. Wir diskutieren die ersten beiden Ansätze, die beinhalten Dezentralisierung, in diesem Abschnitt.
In Abschnitt 6 diskutieren wir unsere langfristige Strategie für vertrauenswürdige Hardware, einen anderen
und komplementären Ansatz.

4.1 Quellen verteilen
Ein einfacher Weg, um mit einer fehlerhaften Einzelquelle umzugehen Src ist es, Daten von zu erhalten mehrere
Quellen, dh verteilen Sie die Datenquelle. Ein vertrauenswürdiger ORAKEL kann eine Sammlung abfragen
von Quellen Src 1 , Src 2 ,. . . , Src k , Antworten erhalten ein 1, ein 2 ,. . . , ein k, und aggregieren sie in
eine einzige Antwort A = agg ( ein 1, ein 2 ,. . . , ein k). ORAKEL Dies kann auf verschiedene Arten geschehen.
Eine davon ist beispielsweise die Mehrheitsentscheidung. Wenn die meisten Quellen die
identischer Wert ein, die Funktion agg kehrt zurück ein; Andernfalls wird ein Fehler zurückgegeben. In
diesem Fall vorausgesetzt, dass eine Mehrheit (> k / 2) Quellen funktionieren korrekt, ORAKEL
gibt immer einen korrekten Wert zurück EIN.
Viele alternative Funktionen agg kann die Robustheit gegenüber fehlerhaften Daten sicherstellen oder
Schwankungen der Datenwerte im Laufe der Zeit (z. B. Aktienkurse) behandeln. Beispielsweise, agg
Möglicherweise werden Ausreißer verworfen (z. B. der größte und der kleinste Wert) ein ich) und geben Sie den Mittelwert
der verbleibenden aus.
Natürlich können Fehler über Datenquellen hinweg auf eine Weise korreliert werden, die schwächer wird
die durch Aggregation gegebenen Zusicherungen. Wenn Website Src 1 = EchoEcho.com erhält seine Daten
von Src 2 = TheHorsesMouth.com, ein Fehler bei Src 2 wird immer einen Fehler bei implizieren Src 1 .
Es können auch subtilere Korrelationen zwischen Datenquellen auftreten. Chainlink schlägt auch vor
Forschung zur Kartierung und Berichterstattung der Unabhängigkeit von Datenquellen auf leicht
verdauliche Weise zu betreiben, damit Orakel und Benutzer unerwünschte Korrelationen vermeiden können.

4.2 Orakel verteilen
So wie Quellen verteilt werden können, ist unser idealer Service ORAKEL selbst kann als verteiltes
System angenähert werden. Dies bedeutet, dass anstelle eines einzigen monolithischen Orakels
Knoten Ö , wir können stattdessen eine Sammlung von haben n verschiedene Orakelknoten { Ö 1 , Ö 2 ,. . . , Ö n }.
Jedes Orakel Ö ich kontaktiert seinen eigenen Satz von Datenquellen, die möglicherweise oder möglicherweise nicht

Figur 3: Anfragen werden sowohl auf Orakel als auch auf Datenquellen verteilt. Diese Abbildung zeigt ein Beispiel
für eine solche Verteilung auf zwei Ebenen.

Überlappung mit denen anderer Orakel. Ö ich aggregiert Antworten aus seinen Datenquellen und
gibt eine eigene Antwort aus EIN ich zu einer Abfrage Anf.
Einige dieser Orakel sind möglicherweise fehlerhaft. Also klar die Antworten aller Orakel
EIN 1, EIN 2 ,. . . , EIN n müssen auf vertrauenswürdige Weise zu einem einzigen maßgeblichen Wert zusammengefasst
werden EIN. Aber angesichts der Möglichkeit fehlerhafter Orakel, wo und wie wird dies geschehen
Aggregation in ChainLink?

Erste Lösung: In-Contract-Aggregation. Unsere ursprünglich vorgeschlagene Lösung in
ChainLink wird eine einfache sein In-Contract-Aggregation. CHAINLINK-SC - -
Dies wiederum bezeichnet den Teil von ChainLink in der Kette - aggregiert selbst die Orakelantworten.
(Alternative, CHAINLINK-SC kann einen anderen Aggregationsvertrag nennen, aber der konzeptionellen
Einfachheit halber nehmen wir an, dass die beiden Komponenten einen einzigen Vertrag bilden.)
Mit anderen Worten, CHAINLINK-SC wird berechnen A = Agg ( EIN 1, EIN 2 ,. . . , EIN n) für eine Funktion Agg ( ähnlich
zu agg, wie oben beschrieben) und senden Sie das Ergebnis EIN zu USER-SC.
Dieser Ansatz ist praktisch für kleine n, und hat mehrere unterschiedliche Vorteile:

• • Konzeptionelle Einfachheit: Trotz der Tatsache, dass das Orakel verteilt ist, eine einzige Einheit, CHAINLINK-SC,
führt die Aggregation durch Ausführen durch Agg.

• • Vertrauenswürdigkeit: Wie CHAINLINK-SC Der Code kann öffentlich eingesehen und sein
korrektes Verhalten überprüft werden. (( CHAINLINK-SC wird ein relativ kleiner, einfacher
Code sein.) Zusätzlich CHAINLINK-SC Die Ausführung ist vollständig sichtbar.

Kette. So Benutzer, dh Schöpfer von USER-SC, kann ein hohes Maß an Vertrauen erreichen
im CHAINLINK-SC.

• • Flexibilität: CHAINLINK-SC kann die meisten gewünschten Aggregationsfunktionen implementieren
Agg - die Mehrheitsfunktion, Mittelwertbildung usw.

So einfach es ist, dieser Ansatz stellt eine neuartige und interessante technische Herausforderung dar.
nämlich das Problem von freeloading. Ein betrügerisches Orakel Ö z kann die Reaktion beobachten
EIN ich eines anderen Orakels Ö ich und kopiere es. Auf diese Weise Orakel Ö z Vermeidet die Kosten für die Abfrage von
Datenquellen, die Gebühren pro Abfrage erheben können. Freeloading schwächt die Sicherheit
Indem Sie die Vielfalt der Datenquellenabfragen untergraben und Orakel davon abhalten, schnell
zu reagieren: Langsam zu reagieren und frei zu laden, ist eine billigere Strategie.
Wir schlagen eine bekannte Lösung für dieses Problem vor, nämlich die Verwendung eines
Festschreibungs- / Offenlegungsschemas. In einer ersten Runde senden Orakel CHAINLINK-SC kryptografische
Verpflichtungen zu ihren Antworten. Nach dem CHAINLINK-SC hat ein Quorum von Antworten erhalten, es
leitet eine zweite Runde ein, in der Orakel ihre Antworten enthüllen.
Algorithmus 1 zeigt ein einfaches sequentielles Protokoll, das die gegebene Verfügbarkeit garantiert
3 f + 1 Knoten. Es verwendet ein Festschreibungs- / Offenlegungsschema, um das freie Laden zu verhindern.
Oracle-Antworten werden freigegeben und sind daher nur einem potenziellen Freeloader ausgesetzt nach dem Alle
Verpflichtungen wurden eingegangen, wodurch der Freeloader vom Kopieren der Antworten anderer Orakel
ausgeschlossen wurde.
On-Chain-Protokolle können Blockzeiten nutzen, um synchrone Protokolldesigns zu unterstützen. In
ChainLink erhalten Oracle-Knoten jedoch Daten von Quellen, die möglicherweise sehr unterschiedliche
Antwortzeiten aufweisen, und die Aufhebungszeiten für Knoten können variieren aufgrund von:
zB Verwendung unterschiedlicher Gaspreise in Ethereum. Um die schnellstmögliche
Reaktionsfähigkeit des Protokolls zu gewährleisten, hat Alg. 1 ist als asynchrones Protokoll ausgelegt.
Hier, Verpflichten r ( EIN) bezeichnet eine Wertverpflichtung EIN mit Zeuge r, während SID
bezeichnet den Satz gültiger Sitzungs-IDs. Das Protokoll geht von authentifizierten Kanälen aus
unter allen Spielern.
Es ist leicht zu sehen, dass Alg. 1 wird erfolgreich beendet. Gegeben 3 f + 1 Knoten insgesamt
höchstens f sind also zumindest fehlerhaft 2 f + 1 sendet Zusagen in Schritt 4. Von diesen Zusagen
höchstens f kommen also zumindest von fehlerhaften Knoten f + 1 kommen von ehrlichen Knoten. Alle
derartigen Verpflichtungen werden schließlich aufgehoben.
Außerdem ist das leicht zu erkennen EIN wird in Alg.1 korrekt sein. Des f + 1
Aufhebungen auf den Einzelwert EIN, Mindestens einer muss von einem ehrlichen Knoten kommen.
In-Contract-Aggregation über Alg. 1 wird kurzfristig der Hauptansatz sein, der von ChainLink
unterstützt wird. Die vorgeschlagene anfängliche Implementierung wird eine komplexere,
gleichzeitige Variante des Algorithmus beinhalten. Unser längerfristiger Vorschlag spiegelt sich
in dem etwas komplizierteren Protokoll wider OCA ( O ﬀ -Kettenaggregation), angegeben in den
Algorithmen 2 und 3 in Anhang A. OCA ist ein O-Ketten-Aggregationsprotokoll, das

Algorithmus 1 InChainAgg ({ Ö ich } ni = 1) ( Code für CHAINLINK-SC)
1: Warte bis Anf wird empfangen von USER-SC.
2: sid ← $ SID
3: Übertragung ( Anfrage, sid).
4: Warten Sie, bis es eingestellt ist C. von 2 f + 1 Mitteilungen ( verpflichten, c i = Verpflichten r ich (( EIN ich), sid) von verschieden
Ö ich empfangen werden.

5: Übertragung ( engagiert sein, sid).
6: Warten Sie, bis es eingestellt ist D. von f + 1 eindeutige gültige Aufhebungen ( aufheben, ( r ich, EIN ich), sid)

werden wo für einige empfangen EIN, alle EIN i = EIN.
7: Senden ( Antworten, EIN, sid) zu USER-SC.

Minimiert die Transaktionskosten in der Kette. Dieses Protokoll umfasst auch die Zahlung an Orakelknoten
und stellt sicher, dass keine Zahlungen an Freeloader erfolgen.

Mittelfristige Strategie: O-Ketten-Aggregation. In-Contract-Aggregation hat
Ein wesentlicher Nachteil: Kosten. Es entstehen die Kosten für die Übertragung und Verarbeitung von
Kette Auf) Orakelnachrichten (begeht und enthüllt für EIN 1, EIN 2 ,. . . , EIN n). In zulässigen
Blockchains kann dieser Overhead akzeptabel sein. In erlaubnislosen Blockchains mit on-
Ketten-Transaktionsgebühren wie Ethereum, wenn n groß ist, können die Kosten unerschwinglich sein. Ein
kostengünstigerer Ansatz besteht darin, Orakelantworten über die Kette zu aggregieren und eine einzelne
Nachricht an zu senden CHAINLINK-SC EIN. Wir schlagen die Anwendung dieses Ansatzes vor
o ﬀ -Kettenaggregation, mittel- bis langfristig.
Das Problem, einen Konsenswert zu erreichen EIN Angesichts potenziell fehlerhafter Knoten ist das Problem des
Konsenses, das Blockchains selbst untermauert, sehr ähnlich. Bei einer vorgegebenen Menge von Orakeln könnte man in
Betracht ziehen, einen klassischen BFT-Konsensalgorithmus (Byzantine Fault Tolerant) zur Berechnung zu verwenden EIN. Klassische
BFT-Protokolle sollen jedoch sicherstellen, dass am Ende eines Protokollaufrufs alle ehrlichen Knoten denselben Wert
speichern, z. B. in einer Blockchain, dass alle Knoten denselben neuen Block speichern. In unserer Orakeleinstellung ist das
Ziel etwas anders. Das wollen wir sicherstellen CHAINLINK-SC ( und

dann USER-SC) erhält eine aggregierte Antwort A = Agg ( EIN 1, EIN 2 ,. . . , EIN n) ohne am
Konsensprotokoll teilzunehmen und ohne Antworten von mehreren erhalten zu müssen
Orakel. Darüber hinaus muss das Problem des freien Ladens noch angegangen werden.
Das ChainLink-System schlägt die Verwendung eines einfachen Protokolls mit Schwellensignaturen vor. Solche
Signaturen können mit einer Reihe von Signaturschemata realisiert werden, sind jedoch mit Schnorr-Signaturen besonders
einfach zu implementieren [4]. Bei diesem Ansatz haben Orakel einen kollektiven öffentlichen Schlüssel pk und einen
entsprechenden privaten Schlüssel sk
das wird unter geteilt Ö 1 , Ö 2 ,. . . , Ö n in einem ( t, n) - Schwellenwert [3]. Eine solche gemeinsame Nutzung bedeutet,
dass jeder Knoten Ö ich hat ein eindeutiges privates / öffentliches Schlüsselpaar ( sk ich, pk ich). Ö ich können

Figur 4: Sig sk [ EIN] kann durch jedes n / 2 + 1 der Orakel erreicht werden.

Generieren Sie eine Teilsignatur σ i = Sig sk ich [ EIN ich] das kann in Bezug auf überprüft werden pk ich.
Das Hauptmerkmal dieses Setups ist, dass Teilsignaturen denselben Wert haben EIN können
über einen beliebigen Satz von aggregiert werden t Orakel, um eine einzige gültige zu ergeben kollektiv Unterschrift

Σ = Sig sk [ EIN] auf eine Antwort EIN. Kein Satz von t - - 1 Orakel können jedoch eine gültige Signatur für
jeden Wert erzeugen. Die einzelne Unterschrift Σ verkörpert also implizit das Partielle
Unterschriften von mindestens t Orakel.
Schwellensignaturen können durch Vermieten naiv realisiert werden Σ bestehen explizit aus einer
Menge von t gültige, unabhängige Signaturen von einzelnen Knoten. Schwellenwertsignaturen haben
ähnliche Sicherheitseigenschaften wie dieser naive Ansatz. Sie bieten jedoch eine signifikante Verbesserung
der Onchain-Leistung: Sie reduzieren die Größe und die Kosten der Überprüfung Σ um einen Faktor von t.

Mit diesem Setup scheint es, dass Orakel nur Teilsignaturen erzeugen und senden können,
bis t solche Teilsignaturen ermöglichen die Berechnung von Σ. Wiederum tritt jedoch das
Problem des freien Ladens auf. Wir müssen daher dafür sorgen, dass Orakel wirklich
Erhalten Sie Daten von den angegebenen Quellen, anstatt zu betrügen und zu kopieren EIN ich von einem
anderen Orakel. Unsere Lösung beinhaltet einen Finanzmechanismus: Ein Unternehmen ANBIETER
(als intelligenter Vertrag realisierbar) belohnt nur Orakel, die Originaldaten für ihre
Teilsignaturen bezogen haben.
In einer verteilten Umgebung erweist es sich als schwierig, festzustellen, welche Orakel zur
Zahlung berechtigt sind. Orakel können miteinander kommunizieren und wir haben keine
einzige maßgebliche Einheit mehr ( CHAINLINK-SC) Antworten erhalten und sind daher un-

fünfzehn

in der Lage, berechtigte Zahlungsempfänger direkt unter den teilnehmenden Orakeln zu identifizieren. Folglich,
ANBIETER muss von den Orakeln selbst Beweise für Fehlverhalten erhalten, von denen einige
möglicherweise nicht vertrauenswürdig sind. Wir schlagen die Verwendung konsensähnlicher
Mechanismen in unserer Lösung für ChainLink vor, um dies sicherzustellen ANBIETER zahlt keine
freeloading Orakel.
Das von uns für ChainLink vorgeschlagene O-Ketten-Aggregationssystem mit den dazugehörigen
sicherheitssicheren Skizzen finden Sie in Anhang A. Es verwendet ein verteiltes Protokoll, das auf
Schwellenwertsignaturen basiert und Widerstand gegen das freie Laden durch bietet
f f fehlerhafte Orakel.
Zu diesem Zweck schlagen wir die Verwendung von vier Schlüsseln vor Sicherheitsdienste: ein Validierungssystem,

ein Reputationssystem, ein Zertifizierungsservice, und ein Vertrags-Upgrade-Service. Alle diese Dienste
können zunächst von einem Unternehmen oder einer Gruppe ausgeführt werden, die am Start des
ChainLink-Netzwerks interessiert sind, sind jedoch dafür ausgelegt Arbeiten Sie streng nach der
ChainLink-Philosophie des dezentralen Designs. Die von ChainLink vorgeschlagenen
Sicherheitsdienste können die Teilnahme von Orakelknoten nicht blockieren oder Orakelantworten
ändern. Die ersten drei Dienste bieten nur Bewertungen oder Anleitungen für Benutzer, während der
Vertrags-Upgrade-Dienst für Benutzer völlig optional ist. Darüber hinaus sollen diese Dienste
unabhängige Anbieter unterstützen, deren Teilnahme gefördert werden sollte, damit Benutzer
schließlich mehrere Sicherheitsdienste zur Auswahl haben.

5.1 Validierungssystem
Das ChainLink-Validierungssystem überwacht das Orakelverhalten in der Kette und bietet eine objektive
Leistungsmetrik, die den Benutzer bei der Auswahl von Orakeln unterstützen kann. Es wird versuchen,
Orakel zu überwachen, um:

• • Verfügbarkeit: Das Validierungssystem sollte Fehler eines Orakels aufzeichnen, um rechtzeitig
auf Anfragen zu antworten. Es werden laufende Verfügbarkeitsstatistiken erstellt.

• • Richtigkeit: Das Validierungssystem sollte offensichtliche fehlerhafte Antworten eines
Orakels aufzeichnen, gemessen an Abweichungen von den Antworten von Kollegen. 3

In unserem anfänglichen On-Chain-Aggregationssystem in ChainLink ist eine solche Überwachung
unkompliziert, da alle Orakelaktivitäten für sichtbar sind CHAINLINK-SC.
Denken Sie jedoch daran, dass in dem für ChainLink vorgesehenen
O-Chain-Aggregationssystem die Orakel selbst die Aggregation durchführen. Folglich, CHAINLINK-SC
hat keinen direkten Einblick in Orakelantworten und kann die Verfügbarkeit und Korrektheit
selbst nicht überwachen.
Glücklicherweise signieren Orakel ihre Antworten digital und generieren so als Nebeneffekt nicht
widerlegbare Beweise für ihre Antworten. Unser vorgeschlagener Ansatz wird daher darin bestehen,
den Validierungsdienst als einen intelligenten Vertrag zu realisieren, der Orakel für die Vorlage von
Beweisen für abweichende Antworten belohnt. Mit anderen Worten, Orakel würden dazu angeregt,
scheinbar fehlerhaftes Verhalten zu melden.
Die Überwachung der Verfügbarkeit ist etwas schwieriger, da Orakel ihre Fehler bei der Reaktion natürlich
nicht unterschreiben. Stattdessen würde eine vorgeschlagene Protokollverbesserung erfordern, dass Orakel
Bescheinigungen über den Satz von Antworten, die sie von anderen Orakeln erhalten haben, digital signieren. Der
Validierungsvertrag würde dann die Einreichung von Bestätigungssätzen akzeptieren (und erneut belohnen), die
zeigen, dass ein Orakel mit schlechter Leistung gegenüber seinen Kollegen eine konsequente Nichtbeantwortung
aufweist.
Sowohl im On-Chain- als auch im Off-Chain-Fall werden Verfügbarkeits- und
Korrektheitsstatistiken für Orakel angezeigt an der Kette. Benutzer / Entwickler können sie somit
in Echtzeit über ein geeignetes Front-End anzeigen, z. B. ein Dapp in Ethereum oder eine
gleichwertige Anwendung für eine autorisierte Blockchain.

5.2 Reputationssystem
Das für ChainLink vorgeschlagene Reputationssystem würde Benutzerbewertungen von Oracle-Anbietern
und -Knoten aufzeichnen und veröffentlichen und den Benutzern die Möglichkeit bieten, die Oracle-Leistung
ganzheitlich zu bewerten. Validator System-Berichte sind wahrscheinlich ein wichtiger Faktor bei der
Bestimmung des Rufs von Orakeln und bei der Vertrauensstellung dieser Reputationen. Faktoren jenseits
der On-Chain-Historie können jedoch wichtige Informationen über den Orakelknoten liefern

3 "Abweichung" muss datenabhängig definiert werden. Bei einfachen booleschen Antworten - zum Beispiel, ob ein Flug
pünktlich ankam - bedeutet Abweichung einfach eine Antwort, die der der Mehrheit entgegengesetzt ist. Für
beispielsweise die Temperatur einer Stadt, die zwischen Sensoren und Quellen rechtmäßig variieren kann, kann eine
Abweichung eine signifikante numerische Abweichung bedeuten. Natürlich kann aus verschiedenen Gründen, z. B.
aufgrund defekter Sensoren, sogar ein gut funktionierendes Orakel in einem Bruchteil der Zeit von der Mehrheitsantwort
abweichen.

Sicherheitsprofile. Dies kann die Vertrautheit der Benutzer mit den Marken, Betriebseinheiten und
Architekturen von Orakeln einschließen. Wir stellen uns vor, dass das ChainLink-Reputationssystem
eine grundlegende On-Chain-Komponente enthält, in der die Bewertungen der Benutzer für andere
intelligente Verträge verfügbar sind. Darüber hinaus sollten Reputationsmetriken leicht zugänglich
sein, wenn größere Datenmengen effizient verarbeitet und flexibler gewichtet werden können.

Für einen bestimmten Orakeloperator wird zunächst vorgeschlagen, dass das Reputationssystem die
folgenden Metriken unterstützt, sowohl hinsichtlich der Granularität bestimmter Zuweisungstypen (siehe
Abschnitt 2) als auch allgemein für alle von einem Knoten unterstützten Typen:

• • Gesamtzahl der zugewiesenen Anfragen: Die Gesamtzahl der früheren Anfragen, denen ein Orakel
zugestimmt hat, sowohl erfüllt als auch nicht erfüllt.

• • Gesamtzahl der abgeschlossenen Anfragen: Die Gesamtzahl der früheren Anfragen, die ein Orakel erfüllt
hat. Dies kann über die Anzahl der Anforderungen gemittelt werden, die zur Berechnung der Abschlussrate
zugewiesen wurden.

• • Gesamtzahl der akzeptierten Anfragen: Die Gesamtzahl der Anfragen, die bei der Berechnung von
Verträgen im Vergleich zu Peer-Antworten als akzeptabel eingestuft wurden. Dies kann über die insgesamt
zugewiesenen oder insgesamt abgeschlossenen Anforderungen gemittelt werden, um einen Einblick in die
Genauigkeitsraten zu erhalten.

• • Durchschnittliche Antwortzeit: Während es notwendig sein kann, Orakelantworten Zeit zur
Bestätigung zu geben, wird die Aktualität ihrer Antworten hilfreich sein, um die zukünftige Aktualität
zu bestimmen. Die durchschnittliche Antwortzeit wird basierend auf abgeschlossenen
Anforderungen berechnet.

• • Höhe der Strafzahlungen: Wenn Strafzahlungen gesperrt würden, um die Leistung eines
Knotenbetreibers sicherzustellen, wäre das Ergebnis eine finanzielle Metrik für die Verpflichtung
eines Orakelanbieters, sich nicht auf einen „Exit-Scam“ -Angriff einzulassen, bei dem der Anbieter das
Geld der Benutzer nimmt und keine Dienste bereitstellt. Diese Metrik würde sowohl eine zeitliche als
auch eine finanzielle Dimension umfassen.

Hoch angesehene Dienste werden in jedem Markt stark dazu angeregt, sich korrekt zu
verhalten und eine hohe Verfügbarkeit und Leistung sicherzustellen. Negatives
Benutzerfeedback stellt ein erhebliches Risiko für den Markenwert dar, ebenso wie die mit
Fehlverhalten verbundenen Strafen. Infolgedessen erwarten wir einen positiven Kreislauf, in dem
gut funktionierende Orakel einen guten Ruf entwickeln und ein guter Ruf Anreize für eine
anhaltend hohe Leistung schafft.

5.3 Zertifizierungsservice
Während unsere Validierungs- und Reputationssysteme eine breite Palette fehlerhafter Verhaltensweisen von
Orakeln behandeln sollen und in den allermeisten Fällen als Mittel zur Gewährleistung der Systemintegrität
vorgeschlagen werden, kann ChainLink auch einen zusätzlichen Mechanismus enthalten, der als a bezeichnet wird Zertifizierungsservice.
Ihr Ziel ist es, seltene, aber katastrophale Ereignisse zu verhindern und / oder zu beheben, insbesondere Am Stück Betrug
in Form von Sybil und Spiegelung von Angriffen, die wir jetzt erklären.

Sybil und Spiegelungsangriffe. Sowohl unsere einfachen als auch unsere vertraglichen
Aggregationsprotokolle versuchen, das freie Laden im Sinne unehrlicher Knoten zu verhindern, die die
Antworten ehrlicher Knoten kopieren. Aber keiner schützt davor Sybil greift an [ 9]. An solchen
Angriffen ist ein Gegner beteiligt, der mehrere scheinbar unabhängige Orakel kontrolliert. Dieser
Gegner kann versuchen, den Orakelpool zu dominieren, was mehr als verursacht f Orakel, um am
Aggregationsprotokoll teilzunehmen und bereitzustellen falsche Daten zu strategischen Zeiten, z. B.
um große Transaktionen in hochwertigen Verträgen zu beeinflussen. Quorums von betrügerischen
Orakeln können auch nicht nur unter der Kontrolle eines einzelnen Gegners entstehen, sondern auch
durch Absprachen zwischen mehreren Gegnern. Angriffe oder Fehler mit> f Orakel sind insofern
besonders schädlich, als sie allein aufgrund des Verhaltens in der Kette nicht nachweisbar sind.
Um die Betriebskosten zu senken, kann ein Sybil-Angreifer außerdem ein genanntes Verhalten anwenden Spiegeln, in
dem es Orakel veranlasst, individuelle Antworten auf der Grundlage von Daten zu senden, die von a erhalten wurden einzelne
Datenquellenabfrage. Mit anderen Worten, Orakel, die sich schlecht benehmen, können Daten außerhalb der Kette
gemeinsam nutzen, geben jedoch vor, Daten unabhängig voneinander zu beschaffen. Das Spiegeln kommt einem Gegner
zugute, unabhängig davon, ob er falsche Daten sendet oder nicht. Es stellt eine viel weniger schwerwiegende
Sicherheitsbedrohung dar als Datenfälschung, beeinträchtigt jedoch die Sicherheit geringfügig, da die Fehlerkorrektur
aufgrund diversifizierter Abfragen für eine bestimmte Quelle beseitigt wird
Src . Zum Beispiel wenn https://www.datasource.com Gibt fehlerhafte Daten aus, beispielsweise aufgrund eines sporadisch
ausgelösten Fehlers. Mehrere Abfrager erhalten möglicherweise immer noch ein korrektes Mehrheitsergebnis.

Sybil-Angriffe, die im Allgemeinen zu falschen Daten, Spiegelung und Absprachen führen, können durch die
Verwendung vertrauenswürdiger Hardware in unserer langfristigen Strategie beseitigt werden (siehe Abschnitt 6).

Design des Zertifizierungsdienstes. Der ChainLink-Zertifizierungsdienst möchte eine allgemeine
Integritäts- und Verfügbarkeitssicherung bieten und kurz- bis mittelfristig Spiegelungen und
Absprachen von Orakelquoren erkennen und verhindern. Der Zertifizierungsdienst würde
ausstellen Vermerke von hochwertigen Orakelanbietern. Wir betonen erneut, wie oben erwähnt,
dass der Dienst Anbieter nur zum Nutzen der Benutzer bewertet. Es ist nicht dazu gedacht, die
Teilnahme oder Nichtteilnahme von Orakelknoten am System zu diktieren.
Der Zertifizierungsdienst unterstützt Vermerke, die auf verschiedenen Funktionen der Oracle-Bereitstellung und des
Oracle-Verhaltens basieren. Es würde die Validierungssystemstatistik überwachen

auf Orakeln und führen Sie eine Post-hoc-Stichprobenprüfung von Antworten in der Kette durch -
insbesondere bei Transaktionen mit hohem Wert - und vergleichen Sie diese mit Antworten, die direkt aus
seriösen Datenquellen stammen. Angesichts der ausreichenden Nachfrage nach Daten eines
Orakelanbieters erwarten wir einen ausreichenden wirtschaftlichen Anreiz, um Prüfungen von
Orakelanbietern außerhalb der Kette zu rechtfertigen und die Einhaltung relevanter Sicherheitsstandards zu
bestätigen, wie z. B. relevante Kontrollen in der Cloud Controls Matrix der Cloud Security Alliance (CSA) [ 26]
sowie nützliche Sicherheitsinformationen, mit denen sie die Quelle und den Bytecode von Orakeln für ihre
intelligenten Verträge ordnungsgemäß prüfen.
Zusätzlich zu den Reputationsmetriken, automatisierten On-Chain- und automatisierten
O-Chain-Systemen zur Betrugserkennung ist der Zertifizierungsdienst geplant, um Sybil-Angriffe und
andere Missstände zu identifizieren, die automatisierte On-Chain-Systeme nicht können. Wenn zum
Beispiel alle Knoten übereinstimmen, dass der Mond aus grünem Käse besteht, sind sie es
kann verursachen USER-SC diese falsche Tatsache aufzunehmen. MONDKOMPONENTEN = {GRÜNER KÄSE}
wird jedoch in der Blockchain aufgezeichnet und in einer Post-hoc-Überprüfung sichtbar.

5.4 Vertrags-Upgrade-Service
Wie die jüngsten Smart Contract Hacks gezeigt haben, ist das Codieren von kugelsicheren Smart Contracts
eine äußerst herausfordernde Aufgabe [1] [20] [22]. Und selbst wenn ein intelligenter Vertrag korrekt
programmiert wurde, können Umweltveränderungen oder Fehler immer noch zu Sicherheitslücken führen,
z. B. [2].
Aus diesem Grund schlagen wir einen Vertrags-Upgrade-Service vor. Wir betonen, dass die Nutzung dieses
Dienstes völlig optional ist und von den Benutzern kontrolliert wird.
Wenn kurzfristig Schwachstellen entdeckt werden, stellt der Vertrags-Upgrade-Service
einfach einen neuen Satz unterstützender Orakelverträge in ChainLink zur Verfügung. Neu
erstellte anfordernde Smart-Verträge können dann auf die neuen Oracle-Verträge migriert
werden.
Leider würden vorhandene mit dem alten, potenziell anfälligen Satz stecken bleiben. Langfristig
also CHAINLINK-SC würde eine Flagge unterstützen ( MIGFLAG) in Orakelanrufen von anfordernden
Verträgen, die angeben, ob ein Anruf an einen neuen weitergeleitet werden soll oder nicht CHAINLINK-SC
sollte man verfügbar werden. Standardmäßig (dh wenn das Flag fehlt) auf falsch, MIGFLAG Dies würde
es ermöglichen, Verträge anzufordern, von der automatischen Weiterleitung und damit von der
Migration auf die neue Version von zu profitieren CHAINLINK-SC. Um die Weiterleitung zu aktivieren,
veranlasst ein Benutzer seinen anfragenden Vertrag, ChainLink-Anfragen mit zu stellen MIGFLAG = wahr.
(( Benutzer können ihre intelligenten Verträge so gestalten, dass sie diese Flagge ändern, wenn sie von
einem autorisierten Vertragsadministrator eine entsprechende Anweisung in der Kette erhalten.)

Die Migration von Benutzern zu neuen Orakelverträgen fungiert als eine Art „Notluke“, die von
Blockchain-Forschern (siehe z. B. [23]) seit langem als Mechanismus zur Behebung von Fehlern und
zur Behebung von Hacks befürwortet wird, ohne auf so umständliche Ansätze wie zurückzugreifen

Sie können auch lesen