Chainlink: una red Oracle descentralizada

Zusammenfassung

In diesem Whitepaper formulieren wir eine Vision für die Entwicklung von Chainlink, die über die ursprüngliche Konzeption im ursprünglichen Whitepaper Chainlink hinausgeht. Wir sehen voraus Eine zunehmend expansive Rolle für oracle-Netzwerke, eine, in der sie bestehende und neue blockchains ergänzen und verbessern, indem sie schnelle, zuverlässige und schnelle Bereitstellung bieten Vertraulichkeit wahrende universelle Konnektivität und Off-Chain-Berechnung für smart contracts. Die Grundlage unseres Plans ist das, was wir dezentrale Oracle-Netzwerke nennen DONs kurz. Ein DON ist ein Netzwerk, das von einem Komitee aus Chainlink gepflegt wird. Knoten. Es unterstützt eine unbegrenzte Auswahl an oracle-Funktionen Einsatz durch den Ausschuss. Ein DON fungiert somit als leistungsstarke Abstraktionsschicht, Bietet Schnittstellen für smart contracts zu umfangreichen Off-Chain-Ressourcen und in hohem Maße Effiziente und dennoch dezentrale Off-Chain-Rechenressourcen innerhalb des DON selbst. Mit DONs als Sprungbrett plant Chainlink, sich auf Fortschritte in sieben Bereichen zu konzentrieren Schwerpunkte: • Hybride smart contracts: Bietet ein leistungsstarkes, allgemeines Framework zur Erweiterung bestehender smart contract-Funktionen durch sicheres Komponieren in der Kette und Off-Chain-Rechenressourcen in sogenannte Hybrid-smart contracts. • Komplexität abstrahieren: Entwicklern und Benutzern einfach präsentieren Die Funktionalität macht eine Vertrautheit mit komplexen Grundlagen überflüssig Protokolle und Systemgrenzen. • Skalierung: Sicherstellen, dass oracle-Dienste die Latenzen und Durchsätze erreichen die von leistungsstarken dezentralen Systemen gefordert werden. • Vertraulichkeit: Ermöglichung von Systemen der nächsten Generation, die blockchains‘ kombinieren Angeborene Transparenz mit starken neuen Vertraulichkeitsschutzmaßnahmen für sensible Personen Daten. • Auftragsgerechtigkeit bei Transaktionen: Unterstützung der Transaktionssequenzierung in gewisser Weise die für Endbenutzer fair sind und Front-Running- und andere Angriffe verhindern Bots und ausbeuterische Miner. • Vertrauensminimierung: Schaffung einer äußerst vertrauenswürdigen Unterstützungsebene für smart contracts und andere oracle-abhängige Systeme durch Dezentralisierung, starke Verankerung in hochsicheren blockchains, kryptographisch Techniken und kryptoökonomische Garantien. • Anreizbasierte (kryptoökonomische) Sicherheit: Konsequente Entwicklung und robuste Bereitstellung von Mechanismen, die sicherstellen, dass Knoten in DONs starke wirtschaftliche Anreize haben, sich zuverlässig und korrekt zu verhalten, selbst angesichts gut ausgestatteter Gegner. Wir präsentieren vorläufige und laufende Innovationen der Chainlink-Community In jedem dieser Bereiche wird ein Bild der Ausweitung und zunehmenden Verbreitung vermittelt leistungsstarke Funktionen für das Netzwerk Chainlink geplant.

Einführung

Blockchain oracles werden heute oft als dezentrale Dienste mit einem Ziel angesehen: um Daten von Off-Chain-Ressourcen an blockchains weiterzuleiten. Es ist jedoch ein kleiner Schritt, von der Weiterleitung von Daten über die Verarbeitung, Speicherung bis hin zur bidirektionalen Übertragung. Diese Beobachtung rechtfertigt eine viel umfassendere Vorstellung von der Funktionalität von oracles. So auch Erfüllen Sie die wachsenden Serviceanforderungen von smart contracts und werden immer vielfältiger Technologien, die auf oracle Netzwerken basieren. Kurz gesagt, ein oracle kann und muss es tun eine universelle, bidirektionale, rechenfähige Schnittstelle zwischen und zwischen On-Chain- und Off-Chain-Systemen sein. Die Rolle von Oracles im blockchain-Ökosystem besteht darin, sich zu verbessern die Leistung, Funktionalität und Interoperabilität von smart contracts, damit sie es können Bringen Sie neue Vertrauensmodelle und Transparenz in eine Vielzahl von Branchen. Diese Transformation wird durch die Ausweitung des Einsatzes hybrider smart contracts, die verschmelzen, zustande kommen Die besonderen Eigenschaften von blockchains mit den einzigartigen Fähigkeiten von Off-Chain-Systemen wie z oracle Netzwerke und erreichen dadurch eine weitaus größere Reichweite und Leistung als On-Chain-Systeme isoliert. In diesem Whitepaper formulieren wir eine Vision für das, was wir Chainlink 2.0 nennen, eine Weiterentwicklung von Chainlink über die ursprüngliche Konzeption im ursprünglichen Chainlink Whitepaper [98] hinaus. Wir gehen davon aus, dass oracle-Netzwerke eine immer größere Rolle spielen werden Sie ergänzen und verbessern bestehende und neue blockchains, indem sie schnelle, zuverlässige und die Vertraulichkeit wahrende universelle Konnektivität und Berechnung für Hybrid bereitstellen smart contracts. Wir glauben, dass sich oracle Netzwerke sogar zu Versorgungsunternehmen entwickeln werden zum Exportieren hochintegrierter blockchain-Daten in Systeme außerhalb des blockchain Ökosystem. Heutzutage kommen Chainlink Knoten, die von verschiedenen Einheiten betrieben werden, in oracle Netzwerken zusammen, um Daten in sogenannten Berichten an smart contracts weiterzuleiten. Wir können solche einsehen oracle Knoten als Ausschuss ähnlich dem in einem klassischen Konsens blockchain [72], aber mit dem Ziel, bestehende blockchains zu unterstützen, anstatt freistehende Funktionalität bereitzustellen. Mit überprüfbaren Zufallsfunktionen (VRF) und Off-Chain Reporting (OCR) entwickelt sich Chainlink bereits zu einem allgemeinen Framework und einer Infrastruktur für die Bereitstellung der Rechenressourcen, die smart contracts benötigen erweiterte Funktionalität. Die Grundlage unseres Plans für Chainlink 2.0 ist das, was wir Decentralized Oracle nennen Netzwerke, kurz DONs. Da wir den Begriff „oracle Netzwerk“ im eingeführt haben Original Chainlink Whitepaper [98], oracles haben immer umfangreichere Funktionen entwickelt und Breite der Anwendung. In diesem Artikel bieten wir eine neue Definition des Begriffs „gemäß“ an zu unserer Zukunftsvision für das Ökosystem Chainlink. In dieser Ansicht ist ein DON ein Netzwerk verwaltet von einem Komitee aus Chainlink Knoten. Es basiert auf einem Konsensprotokoll unterstützt eine unbegrenzte Anzahl von oracle-Funktionen, die von der zur Bereitstellung ausgewählt wurden Ausschuss. Ein DON fungiert somit als blockchain Abstraktionsschicht und stellt Schnittstellen bereit zu Off-Chain-Ressourcen sowohl für smart contracts als auch für andere Systeme. Es bietet auch Zugang zu hocheffizienten und dennoch dezentralen Off-Chain-Rechenressourcen. Im Allgemeinen, a DON unterstützt Operationen auf einer Hauptkette. Ziel ist es, sichere und flexibleble Hybrid smart contracts, die On-Chain- und Off-Chain-Berechnung mit kombinieren Verbindung zu externen Ressourcen. Wir betonen, dass auch bei der Verwendung von Ausschüssen in DONs, Chainlink selbst bleibt von Natur aus erlaubnislos. DONs dienen als Grundlage einer Erlaubnislosigkeit Framework, in dem Knoten zusammenkommen können, um benutzerdefinierte oracle-Netzwerke zu implementieren ihre eigenen Regime für die Knoteneinbindung, die erlaubt oder nicht erlaubt sein können. Mit DONs als Grundlage planen wir, uns in Chainlink 2.0 auf Fortschritte in sieben Bereichen zu konzentrieren Schlüsselbereiche: hybride smart contracts, Abstraktion der Komplexität, Skalierung, Vertraulichkeit, Auftragsfairness für Transaktionen, Vertrauensminimierung und anreizbasierte (kryptoökonomische) Sicherheit. In dieser Papiereinleitung präsentieren wir einen Überblick über Dezentralisierung Oracle Networks in Abschnitt 1.1 und dann unsere sieben wichtigsten Innovationsbereiche in Abschnitt 1.2. Den Aufbau des restlichen Artikels beschreiben wir in Abschnitt 1.3. 1.1 Dezentrale Oracle-Netzwerke Dezentrale Oracle-Netzwerke sind darauf ausgelegt, die Funktionen zu verbessern und zu erweitern von smart contracts auf einem Ziel blockchain oder einer Hauptkette durch Funktionen, die es sind nicht nativ verfügbar. Sie tun dies, indem sie die drei grundlegenden Ressourcen bereitstellen, die in zu finden sind Computersysteme: Vernetzung, Speicherung und Berechnung. Ein DON möchte anbieten diese Ressourcen mit starken Vertraulichkeits-, Integritäts- und Verfügbarkeitseigenschaften1 als sowie Verantwortlichkeit. DONs werden von Ausschüssen von oracle Knoten gebildet, die zusammenarbeiten, um eine bestimmte Aufgabe zu erfüllen Job anzunehmen oder sich dafür zu entscheiden, eine langfristige Beziehung aufzubauen, um beständige Dienstleistungen zu erbringen an Kunden. DONs sind blockchain-agnostisch konzipiert. Sie versprechen, als zu dienen Ein leistungsstarkes und flexibles Tool für Anwendungsentwickler, mit dem sie Off-Chain-Unterstützung erstellen können ihre smart contracts auf jeder unterstützten Hauptkette. Zwei Arten von Funktionalitäten realisieren die Fähigkeiten eines DON: ausführbare Dateien und Adapter. Ausführbare Dateien sind Programme, die kontinuierlich und dezentral auf dem DON laufen. Obwohl sie die Assets der Hauptkette nicht direkt speichern, bieten sie wichtige Vorteile, darunter eine hohe Leistung und die Möglichkeit, vertrauliche Daten zu verarbeiten Berechnung. Ausführbare Dateien laufen autonom auf einem DON und sind deterministisch Operationen. Sie arbeiten mit Adaptern zusammen, die den DON mit externen Ressourcen verbinden und kann von ausführbaren Dateien aufgerufen werden. Adapter, wie wir sie uns für DONs vorstellen, sind a Verallgemeinerung der externen Adapter in Chainlink heute. Während vorhandene Adapter Normalerweise holen sie Daten nur von Datenquellen ab. Adapter können bidirektional arbeiten. in DONs können sie zusätzlich die gemeinsame Berechnung durch DON-Knoten nutzen, um dies zu erreichen Zusätzliche Funktionen, wie z. B. die Verschlüsselung von Berichten zum datenschutzgerechten Konsum durch eine ausführbare Datei. Um einen Eindruck von der grundlegenden Funktionsweise eines DON zu vermitteln, zeigt Abb. 1 konzeptionell, wie a DON kann verwendet werden, um Berichte an einen blockchain zu senden und so die herkömmliche, vorhandene oracle-Funktionalität zu erreichen. DONs können jedoch viele zusätzliche Funktionen bieten, die jedoch darüber hinausgehen 1Die „CIA-Triade“ der Informationssicherheit [123, S. 26, §2.3.5].Chainlinks bestehende Netzwerke. Innerhalb der allgemeinen Struktur von Abb. 1 gilt beispielsweise: Die ausführbare Datei könnte abgerufene Vermögenspreisdaten auf dem DON aufzeichnen und diese Daten dazu verwenden Berechnen Sie beispielsweise einen nachlaufenden Durchschnitt für seine Berichte. Abbildung 1: Konzeptionelle Abbildung, die als Beispiel zeigt, wie ein dezentrales Oracle-Netzwerk grundlegende oracle-Funktionalitäten realisieren kann, d. h. Off-Chain-Daten an einen Vertrag weiterleiten. Ein Die ausführbare Datei verwendet Adapter, um Off-Chain-Daten abzurufen, auf denen sie berechnet und die Ausgabe sendet über einen anderen Adapter zu einem Ziel blockchain. (Adapter werden durch Code im initiiert DON, dargestellt durch kleine blaue Kästchen; Pfeile zeigen dabei die Richtung des Datenflusses an bestimmtes Beispiel.) Die ausführbare Datei kann außerdem lokal DON lesen und schreiben. Speicher, um den Status beizubehalten und/oder mit anderen ausführbaren Dateien zu kommunizieren. Flexible Vernetzung, Berechnung und Speicherung in DONs, alle hier dargestellt, ermöglichen eine Vielzahl neuartiger Anwendungen. Ein großer Vorteil von DONs ist ihre Fähigkeit, neue blockchain-Dienste zu starten. DONs sind ein Vehikel, mit dem bestehende oracle-Netzwerke schnell Serviceanwendungen bereitstellen können Dies würde heute die Schaffung spezieller Netzwerke erfordern. Wir geben eine Reihe von Beispiele für solche Anwendungen finden Sie in Abschnitt 4. In Abschnitt 3 stellen wir weitere Details zu DONs bereit und beschreiben ihre Fähigkeiten in Bedingungen der Schnittstelle, die sie Entwicklern und Benutzern präsentieren. 1.2 Sieben wichtige Designziele Hier gehen wir kurz auf die sieben oben aufgeführten Schlüsselschwerpunkte für die Entwicklung von ein Chainlink, nämlich:Hybride smart contracts: Im Mittelpunkt unserer Vision für Chainlink steht die Idee der Sicherheit Kombinieren von On-Chain- und Off-Chain-Komponenten in smart contracts. Wir verweisen auf Verträge Umsetzung dieser Idee als hybride smart contracts oder hybride Verträge.2 Blockchains sind und bleiben zwei entscheidende Rollen im dezentralen Service Ökosysteme: Sie sind beide Orte, an denen der Besitz von Kryptowährungen repräsentiert wird und robuste Anker für dezentrale Dienste. Intelligente Verträge müssen daher in der Kette dargestellt oder ausgeführt werden, ihre Möglichkeiten in der Kette sind jedoch stark eingeschränkt. Rein Der On-Chain-Vertragscode ist langsam, teuer und isoliert und kann nicht von der realen Welt profitieren Daten und eine Vielzahl von Funktionalitäten, die in der Kette von Natur aus nicht erreichbar sind, einschließlich verschiedener Formen vertraulicher Berechnungen und der Erzeugung von (Pseudo-)Zufälligkeiten gegen Miner / validator Manipulation usw. Damit smart contracts ihr volles Potenzial ausschöpfen können, sind daher smart contracts erforderlich muss aus zwei Teilen aufgebaut sein: einem On-Chain-Teil (den wir normalerweise mit SC bezeichnen) und ein Off-Chain-Teil, eine ausführbare Datei, die auf einem DON läuft (was wir normalerweise mit bezeichnen). exec). Ziel ist es, mit dem eine sichere Zusammensetzung der On-Chain-Funktionalität zu erreichen Vielzahl von Off-Chain-Diensten, die DONs bereitstellen möchten. Zusammen die beiden Teile einen Hybridvertrag abschließen. Wir stellen die Idee konzeptionell in Abb. 2 dar. Bereits heute Chainlink Dienste3 wie Datenfeeds und VRFs ermöglichen eine sonst unerreichbare Leistung smart contract-Anwendungen, die von DeFi über fair generierte NFTs bis hin zu dezentralen Versicherungen reichen, als erste Schritte in Richtung eines allgemeineren Rahmens. Als Chainlink Dienste Erweitern und leistungsfähiger werden, so auch unsere Vision in diesem Whitepaper wird die Leistung von smart contract-Systemen auf alle blockchains angewendet. Unsere anderen sechs Hauptschwerpunkte in diesem Whitepaper können als Handeln im Service betrachtet werden der erste, übergreifende Hybridvertrag. Bei diesen Schwerpunkten geht es darum, sichtbares zu entfernen Komplexität durch hybride Verträge zu reduzieren und zusätzliche Off-Chain-Dienste zu schaffen, die dies ermöglichen Aufbau immer leistungsfähigerer Hybridverträge und, im Falle einer Vertrauensminimierung, Stärkung der durch Hybridverträge erreichten Sicherheitseigenschaften. Wir verlassen die Idee von Hybridverträgen, die in weiten Teilen des Papiers impliziert sind, aber auch in jeder Kombination davon Die MAINCHAIN-Logik mit einem DON kann als Hybridvertrag betrachtet werden. Komplexität abstrahieren: DONs sind für die dezentrale Nutzung konzipiert Machen Sie Systeme für Entwickler und Benutzer einfacher, indem Sie die oft komplexe Maschinerie abstrahieren hinter dem leistungsstarken und flexiblen Leistungsangebot von DONs. Vorhandene Chainlink-Dienste habe diese Funktion bereits. Beispielsweise stellen Datenfeeds in Chainlink heute On-Chain-Schnittstellen dar, die es Entwicklern nicht erfordern, sich mit Details auf Protokollebene zu befassen, etwa mit den Mitteln, mit denen OCR eine Konsensberichterstattung zwischen a erzwingt 2Die Idee der On-Chain-/Off-Chain-Vertragsgestaltung ist bereits in verschiedenen Kontexten entstanden Formulare, z. B. Layer-2-Systeme, TEE-basierte blockchains [80] usw. Unser Ziel ist die Unterstützung und Verallgemeinerung Diese Ansätze und stellen sicher, dass sie den Off-Chain-Datenzugriff und andere wichtige oracle umfassen können. Dienstleistungen. 3Chainlink-Dienste umfassen eine Vielzahl dezentraler Dienste und Funktionen, die über verfügbar sind das Netzwerk. Sie werden von den zahlreichen Knotenbetreibern angeboten, die in verschiedenen oracle Netzwerken zusammengefasst sind im gesamten Ökosystem.Abbildung 2: Konzeptionelle Abbildung, die die Vertragszusammensetzung in der Kette und außerhalb der Kette darstellt. A Hybrid smart contract 3⃝besteht aus zwei komplementären Komponenten: einer On-Chain Komponente SC 1⃝, resident auf einem blockchain, und eine Off-Chain-Komponente exec 2⃝that wird auf einem DON ausgeführt. Der DON dient auch als Brücke zwischen den beiden Komponenten B. die Verbindung des Hybridvertrags mit Off-Chain-Ressourcen wie Webdiensten usw blockchains, dezentrale Speicherung usw. dezentrale Gruppe von Knoten. DONs gehen einen Schritt weiter in dem Sinne, dass sie das erweitern Leistungsspektrum, für das Chainlink Entwicklern eine Abstraktionsschicht anbieten kann begleitende optimierte Schnittstellen für High-Level-Dienste. In Abschnitt 4 stellen wir mehrere Anwendungsbeispiele vor, die diesen Ansatz verdeutlichen. Wir stellen uns beispielsweise vor, dass Unternehmen DONs als eine Form sicherer Middleware verwenden Verbinden Sie ihre Altsysteme mit blockchains. (Siehe Abschnitt 4.2.) Diese Verwendung von DONs abstrahiert die Komplexität der allgemeinen blockchain-Dynamik (Gebühren, Reorgs usw.). Es auch abstrahiert die Funktionen spezifischer blockchains und ermöglicht so Unternehmen, ihre vorhandenen Systeme mit einer immer größeren Anzahl von blockchain-Systemen zu verbinden ein Bedarf an Fachwissen in diesen Systemen oder allgemeiner in der Entwicklung dezentraler Systeme. Letztendlich ist es unser Ziel, den Abstraktionsgrad von Chainlink zu steigern. bis hin zur Implementierung dessen, was wir als dezentralen Metalayer bezeichnen. So eine Schicht würde die On-Chain-/Off-Chain-Unterscheidung für alle Entwicklerklassen abstrahieren und Benutzer von DApps, was die nahtlose Erstellung und Nutzung dezentraler Dienste ermöglicht.Um den Entwicklungsprozess zu vereinfachen, könnten Entwickler die DApp-Funktionalität im Metalayer als virtuelle Anwendung in einem einheitlichen Maschinenmodell spezifizieren. Sie könnten Verwenden Sie dann einen dezentralen Metallayer-Compiler, um die DApp automatisch als zu instanziieren eine Reihe interoperierender dezentraler Funktionalitäten, die blockchains, DONs und umfassen externe Dienstleistungen. (Einer dieser externen Dienste könnte ein Unternehmenssystem sein, wodurch die Metaschicht für Anwendungen mit älteren Unternehmenssystemen nützlich wird.) So Die Kompilierung ähnelt der Art und Weise, wie moderne Compiler und Software Development Kits (SDKs) Unterstützen Sie generalistische Programmierer dabei, das volle Potenzial heterogener Hardware auszuschöpfen Architekturen, die aus einer Allzweck-CPU und spezialisierter Hardware wie GPUs bestehen, Beschleuniger für maschinelles Lernen oder vertrauenswürdige Enklaven. Abb. 3 stellt diese Idee auf konzeptioneller Ebene dar. Hybride smart contracts sind ein erster Schritt auf dem Weg zu dieser Vision und zu einem Konzept, das wir Metaverträge nennen. Metaverträge sind dezentral codierte Anwendungen Metalayer und umfassen implizit On-Chain-Logik (smart contracts) sowie Off-Chain-Berechnung und Konnektivität zwischen verschiedenen blockchains und bestehenden Off-Chain-Logiken Dienstleistungen. Angesichts des Bedarfs an Sprach- und Compilerunterstützung, neuen Sicherheitsmodellen usw konzeptionelle und technische Harmonisierung unterschiedlicher Technologien, jedoch Realisierung eines echten dezentralen Metalayers ist ein ehrgeiziges Ziel, das wir seit langem anstreben Zeithorizont. Dennoch ist es ein hilfreiches Idealmodell, das man beim Lesen im Hinterkopf behalten sollte Dieses Papier wird hier nicht näher erläutert, aber wir planen, uns bei unserer zukünftigen Arbeit darauf zu konzentrieren Chainlink. Skalierung: Ein Ziel von herausragender Bedeutung bei unseren sich entwickelnden Designs ist die Ermöglichung Chainlink-Netzwerk, um den wachsenden Skalierungsanforderungen des blockchain-Ökosystems gerecht zu werden. Da Netzwerküberlastungen zu einem immer wiederkehrenden Problem bei bestehenden Berechtigungen werden blockchains [86], neue und leistungsfähigere blockchain Designs kommen zum Einsatz, z. B. [103, 120, 203], sowie komplementäre Layer-2-Skalierungstechnologien, z. B. [5, 12, 121, 141, 169, 186, 187]. Oracle-Dienste müssen Latenzen und Durchsätze erreichen die die Leistungsanforderungen dieser Systeme erfüllen und gleichzeitig die Gebühren in der Kette minimieren (z. B. Gaskosten) sowohl für Vertragsbetreiber als auch für normale Benutzer. Mit DONs, Chainlink Die Funktionalität zielt darauf ab, darüber hinauszugehen und eine Leistung zu liefern, die für rein webbasierte Systeme ausreichend ist. DONs erzielen einen Großteil ihrer Leistungssteigerung durch die Verwendung schneller, ausschussbasierter oder erlaubnisfreier Konsensprotokolle, die sie mit den blockchains kombinieren sie unterstützen. Wir erwarten, dass viele DONs mit unterschiedlichen Konfigurationen parallel laufen; Verschiedene DApps und Benutzer können Kompromisse bei den zugrunde liegenden Konsensentscheidungen eingehen entsprechend ihren Anwendungsanforderungen. DONs können faktisch als Layer-2-Technologien betrachtet werden. Wir erwarten das unter Andere Dienste, DONs, unterstützen das Transaction Execution Framework (TEF), das erleichtert die effiziente Integration von DONs und damit oracles mit anderen Hochleistungssystemen Layer-2-Systeme – z. B. rollups, Systeme, die Transaktionen außerhalb der Kette bündeln, um zu erreichen Leistungsverbesserungen. Wir stellen den TEF in Abschnitt 6 vor.

Abbildung 3: Konzeptionelle Abbildung, die die ideale Realisierung einer dezentralen Metaschicht zeigt. Für Um die Entwicklung zu vereinfachen, spezifiziert ein Entwickler eine DApp, die rosa hervorgehoben ist, als virtuelle Anwendung in einem einheitlichen Maschinenmodell. Ein dezentraler Metallayer-Compiler generiert automatisch entsprechende interoperierende Funktionalitäten: smart contracts (bezeichnet mit durch SC), Logik (gekennzeichnet durch exec) auf DONs, Adapter, die eine Verbindung zu externen Zieldiensten herstellen usw., wie in der gelben Hervorhebung angezeigt. Abb. 4 zeigt konzeptionell, wie DONs die Skalierung von blockchain (smart contract) verbessern durch Konzentration der Transaktions- und oracle-Berichtsverarbeitung außerhalb der Kette statt auf der Kette Kette. Diese Verschiebung des Hauptberechnungsorts reduziert die Transaktionslatenz und Senkung der Gebühren bei gleichzeitiger Steigerung des Transaktionsdurchsatzes. Vertraulichkeit: Blockchains bieten beispiellose Transparenz für smart contracts und die von ihnen realisierten Anwendungen. Es besteht jedoch ein grundsätzliches Spannungsverhältnis zwischen Transparenz und Vertraulichkeit. Heutzutage ist beispielsweise die dezentrale Austauschtransaktion der BenutzerAbbildung 4: Konzeptionelle Abbildung, die zeigt, wie dezentrale Oracle-Netzwerke das verbessern Skalierung von blockchain-aktivierten smart contracts. Abbildung A ⃝zeigt ein herkömmliches oracle Architektur. Transaktionen werden direkt an blockchain gesendet, ebenso wie oracle-Berichte. Daher ist der gelb hervorgehobene blockchain der Hauptstandort für die Transaktionsverarbeitung. Abbildung B⃝zeigt die Verwendung eines DON zur Unterstützung von Verträgen auf dem blockchain. A DON Die ausführbare Datei verarbeitet Transaktionen zusammen mit Daten aus externen Systemen und leitet sie weiter Ergebnisse – z. B. gebündelte Transaktionen oder Vertragsstatusänderungen, die sich aus den Auswirkungen der Transaktionen ergeben – an den blockchain. Der gelb hervorgehobene DON ist somit der wichtigste Ort für die Transaktionsverarbeitung. Aktionen werden in der Kette aufgezeichnet, was die Überwachung des Austauschverhaltens erleichtert, aber auch Finanztransaktionen der Nutzer öffentlich sichtbar machen. Ebenso werden Daten an smart weitergeleitet Verträge bleiben in der Kette. Dies macht solche Daten bequem überprüfbar, fungiert aber als ein negativer Anreiz für Datenanbieter, die smart contracts mit sensiblen Daten versorgen möchten proprietäre Daten. Wir glauben, dass oracle Netzwerke eine entscheidende Rolle bei der Beschleunigung der nächsten Generation spielen werden Systeme, die die inhärente Transparenz von blockchains mit neuen Vertraulichkeitsschutzfunktionen kombinieren. In diesem Artikel zeigen wir anhand von drei Hauptansätzen, wie sie dies tun werden: • Adapter zur Wahrung der Vertraulichkeit: Zwei Technologien mit geplanter Bereitstellung In den Netzwerken von Chainlink ermöglichen DECO [234] und Town Crier [233] den Knoten oracle Rufen Sie Daten aus Off-Chain-Systemen auf eine Weise ab, die die Privatsphäre und Daten der Benutzer schützt Vertraulichkeit. Sie werden eine Schlüsselrolle bei der Entwicklung von Adaptern für DONs spielen. (Einzelheiten zu diesen beiden Technologien finden Sie in Abschnitt 3.6.2.) • Vertrauliche Berechnung: DONs können ihre Berechnung einfach vor der Verwendung von blockchains verbergen. Durch die Verwendung sicherer Mehrparteien-Berechnungs- und/oder vertrauenswürdiger Ausführungsumgebungen ist auch eine stärkere Vertraulichkeit in den DON-Knoten möglich Berechnen Sie Daten, für die Sie selbst keinen Einblick haben.

• Unterstützung für vertrauliche Layer-2-Systeme: Das TEF ist darauf ausgelegt, eine Vielzahl von Layer-2-Systemen zu unterstützen, von denen viele Zero-Knowledge-Beweise zur Bereitstellung nutzen verschiedene Formen der Vertraulichkeit von Transaktionen. Wir diskutieren diese Ansätze in Abschnitt 3 (mit zusätzlichen Details in Abschnitt 6, Anhang B.1 und Anhang B.2). Abb. 5 zeigt eine konzeptionelle Ansicht, wie vertrauliche Daten mithilfe vertraulicher Adapter und von externen Quellen zu einem smart contract fließen können vertrauliche Berechnung in einem DON. Abbildung 5: Konzeptdiagramm von Vorgängen zur Wahrung der Vertraulichkeit in einem DON on sensible Daten (gelb hervorgehoben). Sensible Quelldaten (schwarze Kreise) im Web Server werden mit vertraulichkeitserhaltenden Adaptern (blaue, doppelpfeilige Linien) in den DON extrahiert. Der DON empfängt abgeleitete Daten (hohle Kreise) von diesen Adaptern – das Ergebnis der Anwendung einer Funktion oder beispielsweise der Weitergabe von Geheimnissen auf die sensible Quelle Daten. Eine ausführbare Datei auf DON kann vertrauliche Berechnungen auf abgeleitete Daten anwenden um einen Bericht (Doppelkreis) zu erstellen, den er über einen Adapter an den blockchain sendet. Wir glauben, dass leistungsstarke Tools für den Umgang mit vertraulichen Daten ein Ganzes eröffnen werden Anwendungsspektrum. Dazu gehören private dezentrale (und zentralisierte) Finanzierungen, dezentrale Identitäten, kreditbasierte On-Chain-Kredite sowie effizientere und effizientere Finanzierungen benutzerfreundliche Know-Your-Customer- und Akkreditierungsprotokolle, wie wir in Abschnitt 4 besprechen. Auftragsfairness bei Transaktionen: Die heutigen blockchain-Designs haben etwas Schmutziges Offenes Geheimnis: Sie sind flüchtig zentralisiert. Bergleute und validators können Trans-Aktionen, wie auch immer sie sich entscheiden. Die Transaktionsreihenfolge kann auch von Benutzern manipuliert werden eine Funktion der von ihnen gezahlten Netzgebühren (z. B. Gaspreise in Ethereum) und für einige Umfang durch die Nutzung schneller Netzwerkverbindungen. Eine solche Manipulation kann z Nehmen Sie zum Beispiel die Form des Front-Runnings an, bei dem ein strategischer Akteur wie ein Bergmann beteiligt ist beobachtet die Transaktion eines Benutzers und fügt seine eigene ausbeuterische Transaktion in eine frühere ein Position im selben Block – effektiver Diebstahl von Geld vom Benutzer durch Nutzung von Vorkenntnissen über die Transaktion des Benutzers. Beispielsweise kann ein Bot eine Kauforder aufgeben vor einem Benutzer. Es kann dann von der dadurch verursachten Vermögenspreissteigerung profitieren Handel des Benutzers. An vorderster Front einige Bots, die normalen Benutzern schaden – analog zu Hochfrequenz Der Handel an der Wall Street ist bereits weit verbreitet und gut dokumentiert [90], ebenso wie damit verbunden Angriffe wie Backrunning [159] und automatisierte Transaktionsnachahmung [195]. Kürzlich sind sogar Vorschläge aufgetaucht, die Auftragsausbeutung durch Bergleute zu systematisieren [110]. Layer-2-Technologien wie rollups lösen das Problem nicht, sondern führen lediglich zu einer Neuzentralisierung Bestellen und es in die Hände der Entität legen, die eine rollup erstellt. Eines unserer Ziele ist die Einführung eines Dienstes namens Fair Sequencing in Chainlink Dienste (FSS) [137]. FSS hilft smart contract Designern dabei, eine faire Bestellung für ihre Produkte sicherzustellen Transaktionen und vermeiden Sie Front-Running-, Back-Running- und damit verbundene Angriffe auf Benutzertransaktionen sowie andere Arten von Transaktionen, wie z. B. die oracle-Berichtsübertragung. FSS ermöglicht es einem DON, Ideen wie den strengen, zeitlichen Begriff der Ordnungsgerechtigkeit umzusetzen, der in [144] eingeführt wurde. Als Nebeneffekt kann FSS auch das Netzwerk der Benutzer beeinträchtigen Gebühren (z. B. Benzinkosten). Kurz gesagt, in FSS durchlaufen Transaktionen den DON, anstatt direkt an ein Ziel smart contract weiterzuleiten. Der DON ordnet die Transaktionen an und leitet sie dann weiter sie zum Vertrag. Abbildung 6: Beispiel für den Nutzen von FSS. Abb. A ⃝zeigt, wie ein Bergmann seine Ressourcen ausbeutet Zentralisierte Befugnis zur Bestellung von Transaktionen, kann ein Transaktionspaar austauschen: Transaktion 1⃝ kommt vor 2⃝ an, aber der Miner sequenziert es stattdessen nach 2⃝. Im Gegensatz dazu zeigt Abb. B⃝ wie ein DON den Bestellvorgang zwischen DON-Knoten dezentralisiert. Wenn ein Quorum von Ehrliche Knoten erhalten 1⃝vor 2⃝, das FSS bewirkt, dass 1⃝vor 2⃝in der Kette erscheint – Verhinderung der Neuordnung von Minern durch Anhängen vertraglich durchsetzbarer Sequenznummern. Abb. 6 vergleicht Standard-Mining mit FSS. Es zeigt, wie im Standard-MiningDer Prozess der Transaktionsbestellung ist beim Miner zentralisiert und unterliegt daher Manipulation, wie z. B. die Neuordnung eines Transaktionspaars hinsichtlich ihres Eintreffens Zeiten. Im Gegensatz dazu ist der Prozess in FSS dezentral auf DON-Knoten verteilt. Vorausgesetzt FSS ist ein Quorum ehrlicher Knoten und hilft bei der Durchsetzung von Richtlinien wie der zeitlichen Reihenfolge von Transaktionen, wodurch die Manipulationsmöglichkeiten durch Bergleute und andere Unternehmen verringert werden. Da die Benutzer außerdem nicht um bevorzugte Bestellungen auf der Grundlage des Gaspreises konkurrieren müssen, Sie können relativ niedrige Gaspreise zahlen (während Transaktionen aus dem DON gebündelt werden können). für Gaseinsparungen). Vertrauensminimierung: Unser allgemeines Ziel bei der Gestaltung von DONs ist es, eine hohe Qualität zu ermöglichen vertrauenswürdige Unterstützungsebene für smart contracts und andere oracle-abhängige Systeme durch Dezentralisierung, kryptografische Tools und kryptoökonomische Garantien. Ein DON selbst ist dezentral und Benutzer können aus jedem verfügbaren DON wählen unterstützt die Hauptkette, auf der sie operieren oder zusätzliche DONs erzeugen möchten mit Komitees von Knotenpunkten, denen sie vertrauen. Bei einigen Anwendungen, insbesondere smart contracts, Chainlink-Benutzern, kann dies jedoch der Fall sein Bevorzugen Sie ein Vertrauensmodell, das die von einem DON unterstützte Hauptkette als vertrauenswürdiger behandelt als der DON selbst. Für solche Benutzer haben wir bereits die Möglichkeit, sie in das zu integrieren Architektur des Chainlink-Netzwerks eine Reihe von Mechanismen, die Verträge ermöglichen auf einer Hauptkette, um die von DONs bereitgestellten Sicherheitsgarantien zu stärken, während an der Gleichzeitig werden auch Schutzmaßnahmen gegen die Möglichkeit beschädigter Datenquellen durchgesetzt wie zum Beispiel die Webserver, von denen der DON Daten bezieht. Wir beschreiben diese Mechanismen in Abschnitt 7. Sie fallen unter fünf Hauptüberschriften: • Datenquellenauthentifizierung: Tools, die es Datenanbietern ermöglichen, digital zu signieren ihre Daten und stärken dadurch die Überwachungskette zwischen dem Ursprung und Vertrauensvertrag. • DON-Minderheitsberichte: Flags, die von einer Minderheitsteilmenge von DON-Knoten ausgegeben werden beobachtet mehrheitliches Fehlverhalten im DON. • Leitplanken: Logik in einer Hauptkette, die anomale Bedingungen erkennt und pausiert oder die Vertragsausführung stoppt (oder andere Abhilfemaßnahmen einleitet). • Vertrauensminimierte Governance: Verwendung von Aktualisierungen mit schrittweiser Veröffentlichung, um die Inspektion durch die Gemeinschaft zu erleichtern, sowie dezentrale Notfalleingriffe für schnelle Reaktion auf Systemausfälle. • Dezentrale Entitätsauthentifizierung: Verwendung einer Public-Key-Infrastruktur (PKI) zur Identifizieren Sie Entitäten im Netzwerk Chainlink. Abb. 7 zeigt ein konzeptionelles Schema unserer Ziele zur Vertrauensminimierung. Anreizbasierte (kryptoökonomische) Sicherheit: Die Dezentralisierung der Berichtserstellung über oracle-Knoten hinweg trägt zur Gewährleistung der Sicherheit bei, selbst wenn einige Knoten beschädigt sind.

Abbildung 7: Konzeptionelle Darstellung des Vertrauensminimierungsziels von Chainlink, das darin besteht Minimieren Sie den Bedarf der Benutzer an einem korrekten Verhalten des DON und von Datenquellen wie dem Web Server. Gelbe Markierungen in der Abbildung weisen auf Vertrauensminimierungsorte hin: die DON und einzelne oder Minderheitsgruppen von Webservern. Rosa Markierungen kennzeichnen Systemkomponenten die von der Annahme her sehr vertrauenswürdig sind: Verträge auf der blockchain und eine Mehrheit von Webservern, also Webservern in ihrer Gesamtheit. Ebenso wichtig ist es jedoch sicherzustellen, dass Knoten einen finanziellen Anreiz haben, sich korrekt zu verhalten. Abstecken, d. h. die Verpflichtung der Knoten zur Bereitstellung von LINK-Einzahlungen und Slashing Die (Konfiszierung) dieser Einlagen im Falle eines Fehlverhaltens wird in Chainlink eine Schlüsselrolle spielen. Es handelt sich um ein wichtiges Anreizdesign, das bereits in einer Reihe von blockchains verwendet wird. z. B. [81, 103, 120, 204]. Das Abstecken in Chainlink sieht jedoch ganz anders aus als in staking im Standalone-Modus blockchains. Das Abstecken von blockchains zielt darauf ab, Angriffe auf den Konsens zu verhindern. Es hat eine anderes Ziel in Chainlink: Sicherstellung der rechtzeitigen Lieferung korrekter oracle-Berichte. Ein gut konzipiertes staking-System für ein oracle-Netzwerk sollte Angriffe wie Bestechung abwehren für einen Gegner unrentabel, selbst wenn das Ziel ein smart contract mit hohem Wert ist Geldwert. In diesem Artikel stellen wir einen allgemeinen Ansatz für staking in Chainlink mit drei Schlüsseln vor Innovationen:1. Ein leistungsstarkes Gegnermodell, das Angriffe umfasst, die bisher übersehen wurden Ansätze. Ein Beispiel ist das, was wir potenzielle Bestechung nennen. Dies ist eine Form von Bestechung, die bestimmt, welche Knoten unter bestimmten Bedingungen Bestechungsgelder erhalten, z. B. bietet im Voraus garantierte Bestechungsgelder für Knoten an, die ein staking-Mechanismus auswählt zufällig für bestimmte Rollen (z. B. Auslösen einer Berichtsentscheidung). 2. Superlineare staking-Auswirkung, was informell bedeutet, dass ein Gegner, um erfolgreich zu sein, über ein Budget $B verfügen muss, das größer ist als die kombinierten Einzahlungen aller oracle Knoten. Genauer gesagt meinen wir, dass als Funktion von n \(B(n) ≫\)dn in a Netzwerk aus n oracle-Knoten mit jeweils einem festen Einzahlungsbetrag $d (formeller: \(B(n) is asymptotically larger in n than \)dn). Abb. 8 gibt einen konzeptionellen Überblick über diese Eigenschaft. 3. Das Implicit-Incentive Framework (IIF), ein Anreizmodell, das wir entwickelt haben umfassen empirisch messbare Anreize, die über die explizit hinterlegten staking hinausgehen. Mittel, einschließlich der zukünftigen Gebührenmöglichkeiten der Knoten. Das IIF erweitert den Begriff von Einsatz über explizite Node-Einlagen hinaus. Abbildung 8: Konzeptdiagramm, das die superlineare Skalierung in Chainlink staking darstellt. Die Das von einem Gegner geforderte Bestechungsgeld $B(n) wächst in n schneller als die gesamten Einlagen $dn aller oracle Knoten. Wir zeigen, wie der IIF- und der superlineare staking-Einfluss zusammen das bewirken, was wir tun Rufen Sie einen positiven Kreislauf der wirtschaftlichen Sicherheit für oracle-Netzwerke an. Wenn neue Benutzer eintreten

Das System erhöht die potenziellen zukünftigen Einnahmen aus dem Betrieb von Chainlink-Knoten Die Grenzkosten der wirtschaftlichen Sicherheit sinken für aktuelle und zukünftige Nutzer. In einem Regime von Aufgrund der elastischen Nachfrage schaffen diese geringeren Kosten einen Anreiz für zusätzliche Benutzer, die zu nutzen Netzwerk, das die Akzeptanz in einem fortlaufenden positiven Kreislauf kontinuierlich fortsetzt. Hinweis: Dieses Whitepaper beschreibt zwar wichtige Elemente unserer Vision für die Entwicklung von Chainlink, ist jedoch informell und enthält nur wenige detaillierte technische Einzelheiten. Das haben wir vor Veröffentlichung fokussierter technischer Dokumente zu zusätzlichen Funktionen und Ansätzen, während diese sich weiterentwickeln. Darüber hinaus ist es wichtig zu betonen, dass viele Elemente der Vision vorgestellt werden Hier (Skalierungsverbesserungen, Vertraulichkeitstechnologien, FSS usw.) kann und wird es sein in vorläufiger Form bereitgestellt, noch bevor fortgeschrittene DONs zu einer Grundfunktion von werden Chainlink. 1.3 Organisation dieses Papiers Wir stellen unser Sicherheitsmodell und unsere Notation in Abschnitt 2 vor und skizzieren die Dezentralisierung Oracle Network API in Abschnitt 3. In Abschnitt 4 stellen wir eine Reihe von Beispielen vor Anwendungen, für die DONs eine attraktive Bereitstellungsplattform bieten. Leser können Lernen Sie die meisten Schlüsselkonzepte des Artikels kennen, indem Sie bis zu diesem Punkt lesen. Der Rest des Papiers enthält weitere Details. Wir beschreiben Fair Sequencing Services (FSS) in Abschnitt 5 und das Transaction-Execution Framework (TEF) in Abschnitt 6. Wir beschreiben unseren Ansatz zur Vertrauensminimierung in Abschnitt 7. Wir betrachten einige Wichtige DON Bereitstellungsanforderungen, nämlich inkrementelle Einführung von Funktionen, dynamische Ledger-Mitgliedschaft und Verantwortlichkeit in Abschnitt 8. Schließlich geben wir in Abschnitt 9 an Ein Überblick über unseren Entwicklungsansatz für die Gestaltung von Anreizen. Wir schließen mit Abschnitt 10. Um Lesern zu helfen, die mit den Konzepten in diesem Dokument nur begrenzt vertraut sind, haben wir In Anhang A finden Sie ein Glossar. Wir stellen weitere Details zur Schnittstelle DON vor und Funktionalität in Anhang B und stellen Sie einige Beispieladapter in Anhang C vor. In Anhang D beschreiben wir ein kryptografisches Grundelement für eine vertrauensminimierte Datenquelle Authentifizierung namens funktionale Signaturen und führen eine neue Variante namens diskretisierte funktionale Signaturen ein. Wir besprechen einige Überlegungen, die den Ausschuss betreffen Auswahl für DONs in Anhang F.

Sicherheitsmodell und Ziele

Ein dezentrales Oracle-Netzwerk ist ein ausgeprägtes verteiltes System, von dem wir erwarten, dass es so sein wird werden zunächst in der Regel – wenn auch nicht unbedingt – durch einen Ausschuss umgesetzt Konsensprotokoll und wird von einer Reihe von oracle-Knoten ausgeführt. Ein DON ist in erster Linie entworfen um die Fähigkeiten eines smart contract in einer Hauptkette mit oracle-Berichten zu erweitern und andere Dienste, kann aber dieselben unterstützenden Dienste auch für andere Nicht-blockchain-Systeme bereitstellen und muss daher nicht mit einer bestimmten Hauptkette verknüpft sein.

Das von uns betrachtete Modell und die Eigenschaften sind daher weitgehend unabhängig von der Verwendung von die besonderen Anwendungen eines DON. 2.1 Aktuelles Architekturmodell Es ist wichtig zu betonen, dass Chainlink heute kein monolithischer Dienst ist, sondern ein erlaubnisfreier Rahmen, innerhalb dessen es möglich ist, eindeutig und unabhängig zu starten Netzwerke von oracle Knoten [77]. Netzwerke verfügen über heterogene Sätze von Knotenoperatoren und Entwürfe. Sie können sich auch hinsichtlich der Art der von ihnen angebotenen Dienstleistungen unterscheiden, was durchaus möglich ist Dazu gehören beispielsweise Datenfeeds, Reservenachweise, überprüfbare Zufälligkeit usw. Andere Zu den Unterschieden können der Grad der Dezentralisierung und die Größe des Netzwerks gehören gesperrter Wert, den es unterstützt, und verschiedene Service-Level-Parameter, wie z. B. die Datenhäufigkeit und Genauigkeit. Das erlaubnislose Modell von Chainlink fördert das Wachstum eines Ökosystems, in dem Anbieter spezialisieren sich auf die Dienstleistungen, die sie der Gemeinschaft am besten anbieten können. Dies Ein Modell führt wahrscheinlich zu geringeren Kosten für die Benutzer und einer höheren Servicequalität als ein Modell Das erfordert, dass alle Knoten und Netzwerke eine vollständige Palette von Diensten bereitstellen, ein Ansatz Dies kann leicht zu einer systemweiten Einführung der Dienste führen, die am wenigsten repräsentieren gemeinsamer Nenner der den Knoten zur Verfügung stehenden Ressourcen. Während sich Chainlink in Chainlink 2.0 zu DON-basierten Designs weiterentwickelt, machen wir weiter Unterstützen Sie das Modell eines erlaubnislosen, offenen Frameworks und behalten Sie dabei das Ziel im Auge Bereitstellung einer Reihe von Serviceoptionen für Benutzer, die weltweit zu der besten Übereinstimmung führen mit besonderen Anwendungsanforderungen. 2.2 Konsensannahmen Wir verwenden den Begriff „Dezentrales Oracle-Netzwerk“, um die volle Funktionalität von zu umfassen Das oracle-System, das wir beschreiben: sowohl die Datenstruktur, die die oracle-Knoten verwalten, als auch die darüber liegende Kern-API. Wir verwenden den Begriff „Ledger“ (Kleinbuchstabe) mit der Bezeichnung „L“ für die zugrunde liegenden Daten Struktur, die von einem DON verwaltet und zur Unterstützung der jeweiligen bereitgestellten Dienste verwendet wird. Wir betonen, dass unser DON-Framework L nicht als freistehendes System behandelt a blockchain: Sein Zweck ist die Unterstützung von blockchains und anderen Systemen. Blockchains sind, Natürlich gibt es eine Möglichkeit, ein vertrauenswürdiges Hauptbuch zu erstellen, aber es gibt auch andere. Wir erwarten DONs in vielen Fällen, um ihre zugrunde liegenden Hauptbücher mithilfe von Byzantine Fault Tolerant zu realisieren (BFT) Systeme, die erheblich älter sind als blockchains wie Bitcoin [174]. Wir verwenden BFT-Typ-Notation und -Eigenschaften werden im gesamten Artikel der Einfachheit halber verwendet, obwohl wir betonen Sie, dass DONs mithilfe erlaubnisloser Konsensprotokolle realisiert werden können. Konzeptionell ist ein Ledger L ein schwarzes Brett, auf dem Daten linear geordnet sind. Wir gehen davon aus, dass ein Hauptbuch im Allgemeinen einige Schlüsseleigenschaften aufweist, die üblicherweise zugeschrieben werden blockchains [115]. Ein Hauptbuch ist: • Nur anhängen: Einmal hinzugefügte Daten können nicht entfernt oder geändert werden.• Öffentlich: Jeder kann seinen Inhalt lesen, der über die Zeit hinweg konsistent ist Ansicht aller Benutzer.4 • Verfügbar: Das Ledger kann jederzeit von autorisierten Autoren beschrieben und gelesen werden von irgendjemandem rechtzeitig. Alternative Eigenschaften sind im Ledger für einen DON möglich, wenn sie durch a realisiert werden Ausschuss. Beispielsweise kann der Schreibzugriff auf das Hauptbuch auf bestimmte Benutzer beschränkt sein, z könnte für einige Anwendungen Lesezugriff haben, d. h. das Ledger muss nicht wie definiert öffentlich sein oben. Ebenso können Ledger-Regeln die Änderung oder Schwärzung von Daten zulassen. Wir nicht Wir betrachten solche Varianten in dieser Arbeit jedoch explizit. Der modulare Aufbau der DONs kann eine Vielzahl moderner BFTs unterstützen. Protokolle, z. B. Hotstuff[231]. Die genaue Wahl hängt von den Vertrauensannahmen und ab Netzwerkeigenschaften zwischen den oracle-Knoten. Ein DON könnte grundsätzlich alternativ sein Verwenden Sie ein hochleistungsfähiges, erlaubnisloses blockchain für sein Hauptbuch in seiner Rolle, die ein unterstützt gleichermaßen skalierbares Layer-2- oder blockchain-System. Ebenso ist auch eine Hybridisierung möglich: Der DON könnte im Prinzip aus Knoten bestehen, die validators in einem bestehenden sind blockchain, z. B. in Proof-of-Stake-Systemen, in denen Komitees für die Ausführung ausgewählt werden Transaktionen, z. B. [8, 81, 120, 146, 204]. Diese besondere Betriebsart erfordert dies Knoten funktionieren im Dual-Use-Stil, d. h. sie fungieren sowohl als blockchain-Knoten als auch als DON-Knoten. Knoten. (Siehe Abschnitt 8.2 für eine Diskussion der Techniken zur Gewährleistung der Kontinuität bei Veränderungen Ausschüsse und Anhang F für einige Vorbehalte bei der zufälligen Auswahl von Ausschüssen.) In der Praxis signieren Knoten in modernen BFT-Algorithmen Nachrichten im Hauptbuch digital. Der Einfachheit halber gehen wir davon aus, dass L einen zugehörigen öffentlichen Schlüssel pkL und dessen Inhalt hat werden mit dem entsprechenden privaten Schlüssel signiert. Diese allgemeine Notation gilt auch dann, wenn Daten auf L werden mit Schwellenwertsignaturen signiert.5 Schwellenwertsignaturen sind praktisch, da sie eine dauerhafte Identität für einen DON auch bei Änderungen der Mitgliedschaft in ermöglichen die Knoten, auf denen es ausgeführt wird. (Siehe Anhang B.1.3.) Wir gehen daher davon aus, dass skL geheim ist in einer (k, n)-Schwellenwertweise für einen Sicherheitsparameter k, z. B. k = 2f + 1 und n = 3f + 1, wobei f die Anzahl potenziell fehlerhafter Knoten ist. (Durch die Wahl von k in diesem Auf diese Weise stellen wir sicher, dass fehlerhafte Knoten weder skL lernen noch einen Denial-of-Service auslösen können Angriff, der seine Verwendung verhindert.) Eine Nachricht auf L hat die Form M = (m, z), wobei m eine Zeichenfolge und z ein eindeutiger Wert ist fortlaufende Indexnummer. Gegebenenfalls schreiben wir Nachrichten in der Form m = ⟨MessageType: Nutzlast⟩. Der Nachrichtentyp MessageType ist ein syntaktischer Zucker, der die Funktion einer bestimmten Nachricht angibt. 4In Fällen, in denen ein blockchain ohne Endgültigkeit ein Hauptbuch realisiert, wird die Inkonsistenz typischerweise abstrahiert durch das Ignorieren nicht ausreichend tiefer Blöcke oder das „Beschneiden“ von [115] beseitigt werden. 5In der Praxis wurden derzeit einige Codebasen übernommen, z. B. LibraBFT [205], eine Variante von Hotstuff Mehrfachsignaturen anstelle von Schwellenwertsignaturen bieten eine geringere Kommunikationskomplexität einfachere Technik. Mit etwas zusätzlichem Aufwand können oracle-Knoten Schwellenwertsignaturen an Nachrichten anhängen an L geschrieben, auch wenn das für L verwendete Konsensprotokoll sie nicht verwendet.2.3 Notation Wir bezeichnen die Menge von n oracle-Knoten, die das Hauptbuch ausführen, mit O = {Oi}n i=1. So ein Diese Gruppe von Knoten wird oft als Komitee bezeichnet. Der Einfachheit halber gehen wir davon aus, dass die Menge von oracles, die die Funktionalität von DON implementieren, d. h. Dienste zusätzlich zu L, sind identisch mit dass L beibehalten wird, aber sie können verschieden sein. Wir lassen pki den öffentlichen Schlüssel von bezeichnen Spieler Oi und skizzieren Sie den entsprechenden privaten Schlüssel. Die meisten BFT-Algorithmen erfordern mindestens n = 3f + 1 Knoten, wobei f die Anzahl der Knoten ist potenziell fehlerhafte Knoten; Die übrigen Knoten sind ehrlich in dem Sinne, dass sie dem folgen Protokoll genau wie angegeben. Wir bezeichnen das Komitee O als ehrlich, wenn es dies erfüllt Anforderung, d. h. sie hat mehr als 2/3 der ehrlichen Knoten. Sofern nicht anders Wir gehen davon aus, dass O ehrlich ist (und ein statisches Modell der Korruption). Wir verwenden pkO / skO austauschbar mit pkL / skL, je nach Kontext. Wir lassen σ = Sigpk[m] eine Signatur auf Nachricht m in Bezug auf pk, d. h. using, bezeichnen entsprechender privater Schlüssel sk. Verifizieren(pk, σ, m) →{false, true} bezeichne einen entsprechenden Signaturverifizierungsalgorithmus. (Wir lassen die Schlüsselgenerierung im gesamten Artikel implizit.) Wir verwenden die Notation S, um eine Datenquelle zu bezeichnen, und S, um den vollständigen Satz davon zu bezeichnen NS-Quellen in einem bestimmten Kontext. Wir bezeichnen mit MAINCHAIN einen Smart-Contract-fähigen blockchain unterstützt von einem DON. Wir verwenden den Begriff „verlassender Vertrag“, um jeden Smart zu bezeichnen Vertrag auf MAINCHAIN, der mit einem DON kommuniziert, und verwenden Sie die Notation SC dazu bezeichnen einen solchen Vertrag. Wir gehen im Allgemeinen davon aus, dass ein DON eine einzelne Hauptkette MAINCHAIN unterstützt, obwohl er mehrere solcher Ketten unterstützen kann, wie wir in Beispielen in Abschnitt 4 zeigen. A DON kann und wird in der Regel mehrere abhängige Verträge auf MAINCHAIN unterstützen. (Wie Wie oben erwähnt, kann ein DON alternativ auch Nicht-blockchain-Dienste unterstützen.) 2.4 Hinweis zu Vertrauensmodellen Wie oben erwähnt, können DONs auf der Grundlage ausschussbasierter Konsensprotokolle erstellt werden, und wir gehen davon aus, dass sie solche Protokolle häufig verwenden werden. Dafür gibt es viele starke Argumente Eine der beiden Alternativen, ausschussbasierte oder erlaubnislose blockchains, bietet stärkere Sicherheit als die anderen. Es ist wichtig zu erkennen, dass die Sicherheit ausschussbasiert vs. erlaubnislos ist dezentrale Systeme sind inkommensurabel. Gefährdung eines PoW oder eines PoS blockchain Durch einen 51-Prozent-Angriff ist es erforderlich, dass ein Gegner kurzzeitig die Mehrheitsressourcen erhält potenziell anonym, zum Beispiel durch die Anmietung von hash Strom in einem PoW-System. So Angriffe in der Praxis haben bereits mehrere blockchains betroffen [200, 34]. Im Gegensatz dazu Die Kompromittierung eines ausschussbasierten Systems bedeutet, dass eine bestimmte Anzahl (in der Regel ein Drittel) seiner Knoten korrumpiert wird, wobei die Knoten öffentlich bekannt und gut ausgestattet sein können. und vertrauenswürdige Unternehmen. Auf der anderen Seite sind gremiumsbasierte Systeme (sowie „hybride“ erlaubnislose Systeme). Systeme, die Ausschüsse unterstützen) können mehr Funktionalität unterstützen als streng vorgeschriebenemissionslose Systeme. Dazu gehört die Fähigkeit, persistente Geheimnisse zu bewahren, wie z Signierungs- und/oder Verschlüsselungsschlüssel – eine Möglichkeit in unseren Designs. Wir betonen, dass DONs grundsätzlich entweder auf einer ausschussbasierten oder einer ausschussbasierten Grundlage aufgebaut werden können Erlaubnisloses Konsensprotokoll und DON-Bereitsteller können sich letztendlich für die Übernahme entscheiden Beide Ansätze. Vertrauensmodelle stärken: Ein wesentliches Merkmal von Chainlink ist heute die Fähigkeit der Benutzer, dies zu tun Wählen Sie Knoten basierend auf dezentralen Aufzeichnungen ihrer Leistungsverläufe aus, wie besprochen in Abschnitt 3.6.4. Der staking-Mechanismus und das implizite Anreiz-Framework, die wir in Abschnitt 9 vorstellen, bilden zusammen ein weitreichendes und strenges Mechanismusdesign Framework, das Benutzern eine deutlich erweiterte Möglichkeit bietet, die Sicherheit von DONs zu beurteilen. Dasselbe Framework wird es auch für DONs selbst ermöglichen um verschiedene Sicherheitsanforderungen an den teilnehmenden Knoten durchzusetzen und den Betrieb sicherzustellen innerhalb starker Vertrauensmodelle. Es ist auch möglich, mithilfe der in diesem Dokument beschriebenen Tools für DONs spezielle Vertrauensmodellanforderungen durchzusetzen, beispielsweise die Einhaltung gesetzlicher Anforderungen. Für Mithilfe der in Abschnitt 4.3 besprochenen Techniken können Knoten beispielsweise Beweise dafür liefern Merkmale des Knotenbetreibers, z. B. das Einsatzgebiet, die zur Unterstützung genutzt werden können Durchsetzung der Einhaltung z. B. der Datenschutz-Grundverordnung (DSGVO), Artikel 3 („Territorialer Geltungsbereich“) [105]. Eine solche Einhaltung kann ansonsten eine Herausforderung darstellen treffen sich in dezentralen Systemen [45]. Darüber hinaus diskutieren wir in Abschnitt 7 Pläne zur Stärkung der Robustheit von DONs durch Vertrauensminimierungsmechanismen in den Hauptketten, die sie unterstützen.

Dezentrale Oracle-Netzwerkschnittstelle und Ca-

Fähigkeiten Hier skizzieren wir kurz die Fähigkeiten von DONs im Sinne des Einfachen, aber Leistungsstarken Schnittstelle, die sie realisieren sollen. Anwendungen auf einem DON bestehen aus ausführbaren Dateien und Adaptern. Eine ausführbare Datei ist ein Programm, dessen Kernlogik ein deterministisches Programm ist, analog zu einem smart contract. Eine ausführbare Datei verfügt auch über eine Reihe begleitender Initiatoren, also Programme, die den Eintrag aufrufen Punkte in der Logik der ausführbaren Datei, an denen vorgegebene Ereignisse auftreten – z. B. zu bestimmten Zeiten (wie ein Cron-Job), wenn ein Preis einen Schwellenwert überschreitet usw. – ähnlich wie bei Keepers (siehe Abschnitt 3.6.3). Adapter stellen Schnittstellen zu Off-Chain-Ressourcen bereit und können von aufgerufen werden entweder die Initiatoren oder die Kernlogik in ausführbaren Dateien. Davon kann ihr Verhalten abhängen In Bezug auf externe Ressourcen verhalten sich Initiatoren und Adapter möglicherweise nicht deterministisch. Wir beschreiben die Entwicklerschnittstelle DON und die Funktionsweise von ausführbaren Dateien und Adapter im Hinblick auf die drei Ressourcen, die typischerweise zur Charakterisierung von Computersystemen verwendet werden: Netzwerk, Rechenleistung und Speicher. Wir geben jeweils einen kurzen Überblick darüber Weitere Informationen finden Sie im Anhang B.

3.1 Vernetzung Adapter sind Schnittstellen, über die ausführbare Dateien, die auf einem DON ausgeführt werden, senden und Daten von Off-DON-Systemen empfangen. Adapter können als eine Verallgemeinerung von angesehen werden Die in Chainlink verwendeten Adapter sind heute [20]. Adapter können bidirektional sein – d. h. sie kann Daten nicht einfach von einem DON an einen Webserver ziehen, sondern pushen. Sie können auch eine Hebelwirkung erzielen verteilte Protokolle sowie kryptografische Funktionen wie sicheres Mehrparteiensystem Berechnung. Abbildung 9: Adapter, die einen DON, bezeichnet als DON1, mit einer Reihe verschiedener Ressourcen verbinden, einschließlich eines weiteren DON, bezeichnet als DON2, eines blockchain (Hauptkette) und dessen Mempool, externer Speicher, ein Webserver und IoT-Geräte (über einen Webserver). Es werden Beispiele für externe Ressourcen angezeigt, für die Adapter erstellt werden könnten in Abb. 9. Dazu gehören: • Blockchains: Ein Adapter kann definieren, wie Transaktionen an einen blockchain und gesendet werden wie man Blöcke, einzelne Transaktionen oder andere Zustände daraus liest. Ein Adapter kann auch für den Mempool eines blockchain definiert werden. (Siehe Abschnitt 3.5.) • Webserver: Adapter können APIs definieren, über die Daten abgerufen werden können von Webservern, einschließlich Legacy-Systemen, die nicht speziell dafür angepasst sind Schnittstelle zu DONs. Solche Adapter können auch APIs zum Senden von Daten enthalten solche Server. Die Webserver, mit denen sich ein DON verbindet, können als Gateways dienen auf zusätzliche Ressourcen wie Internet-of-Things (IoT)-Geräte.• Externer Speicher: Ein Adapter kann Methoden zum Lesen und Schreiben im Speicher definieren Dienste außerhalb des DON, wie etwa ein dezentrales Dateisystem [40, 188] oder eine Cloud Lagerung. • Andere DONs: Adapter können Daten zwischen DONs abrufen und übertragen. Wir gehen davon aus, dass die ersten Bereitstellungen von DONs eine Reihe von Bausteinen umfassen werden Adapter für solche häufig verwendeten externen Ressourcen und ermöglichen darüber hinaus DON-spezifische Adapter, die von DON-Knoten veröffentlicht werden sollen. Als smart contract schreiben Entwickler Adapter Heute gehen wir davon aus, dass sie mit dieser fortschrittlichen Technologie noch leistungsfähigere Adapter bauen werden Funktionalität. Wir gehen davon aus, dass es Benutzern letztendlich möglich sein wird, neue Adapter zu erstellen erlaubnislose Art und Weise. Einige Adapter müssen so konstruiert sein, dass die Persistenz und Verfügbarkeit externer Ressourcen gewährleistet ist, die von einem DON gesteuert werden. Beispielsweise kann es sich um einen Cloud-Speicher handeln erfordern die Führung eines Cloud-Services-Kontos. Zusätzlich kann ein DON ausgeführt werden dezentrale Verwaltung privater Schlüssel im Auftrag von Benutzern (wie z. B. [160]) und/oder ausführbare Dateien. Folglich ist DON in der Lage, Ressourcen wie Kryptowährungen zu steuern, die beispielsweise zum Senden von Transaktionen an ein Ziel blockchain verwendet werden können. Weitere Einzelheiten zu DON-Adaptern finden Sie in Anhang B.1 und in Anhang C für einige Beispieladapter. 3.2 Berechnung Eine ausführbare Datei ist die grundlegende Codeeinheit auf einem DON. Eine ausführbare Datei ist ein Paar exec = (Logik, Init). Hier ist Logik ein deterministisches Programm mit einer Reihe bezeichneter Einträge Punkte (Logik1, Logik2, ..., Logikℓ) und init ist eine Menge entsprechender Initiatoren (init1, init2, . . . , inite). Um die vollständige Überprüfbarkeit von DON, der Logik einer ausführbaren Datei, sicherzustellen verwendet das zugrunde liegende Hauptbuch L für alle Ein- und Ausgänge. Also zum Beispiel jeder Adapter Daten, die als Eingabe für eine ausführbare Datei dienen, müssen zuerst auf L gespeichert werden. Initiatoren: Initiatoren in Chainlink führen heute zu ereignisabhängigen Jobausführungen Chainlink Knoten [21]. Initiatoren in DONs funktionieren auf ähnliche Weise. Ein DON-Initiator ist jedoch speziell einer ausführbaren Datei zugeordnet. Ein Initiator kann davon abhängen auf ein externes Ereignis oder einen externen Status, auf die aktuelle Zeit oder auf ein Prädikat für den Status DON. Aufgrund ihrer Abhängigkeit von Ereignissen können sich Initiatoren natürlich nichtdeterministisch verhalten (wie natürlich auch Adapter). Ein Initiator kann innerhalb einzelner DON-Knoten ausgeführt werden und sind daher nicht auf einen Adapter angewiesen. (Siehe Beispiel 1 unten.) Initiatoren sind ein wichtiges Merkmal, das ausführbare Dateien von smart contracts unterscheidet. Da eine ausführbare Datei als Reaktion auf einen Initiator ausgeführt werden kann, kann sie effektiv funktionieren autonom, wie natürlich auch als Erweiterung ein Hybridvertrag mit der ausführbaren Datei möglich ist. Eine Form von Initiatoren sind heute Chainlink Keeper, die Transaktionen bereitstellenAutomatisierungsdienste, die die Ausführung von smart contract auslösen – beispielsweise die Liquidation unterbesicherter Kredite und die Ausführung von Limit-Order-Geschäften – basierend auf oracle-Berichten. Praktischerweise können Initiatoren in DONs auch als eine Möglichkeit zur Angabe der angesehen werden Servicevereinbarungen, die für eine ausführbare Datei gelten, da sie die Umstände darunter definieren wie der DON es nennen muss. Das folgende Beispiel veranschaulicht, wie Initiatoren innerhalb einer ausführbaren Datei funktionieren: Beispiel 1 (Abweichungsgesteuerter Preis-Feed). Ein smart contract SC erfordert möglicherweise frisches Preis-Feed-Daten (siehe Abschnitt 3.6.3) immer dann, wenn sich eine wesentliche Änderung, z. B. 1 %, ergibt der Wechselkurs zwischen einem Paar von Vermögenswerten, z. B. ETH-USD. Volatilitätsempfindlicher Preis Feeds werden heute in Chainlink unterstützt, aber es ist aufschlussreich zu sehen, wie sie sein können realisiert auf einem DON mittels einer ausführbaren Datei execfeed. Die ausführbare Datei execfeed verwaltet den aktuellsten ETH-USD-Preis r auf L, im Form einer Folge von ⟨NewPrice : j, r⟩Einträgen, wobei j ein Index ist, der mit inkrementiert wird jede Preisaktualisierung. Ein Initiator init1 veranlasst jeden Knoten Oi, den aktuellen ETH-USD-Preis zu überwachen Abweichungen von mindestens 1 % vom zuletzt gespeicherten Preis r mit Index j. Auf Wenn Oi eine solche Abweichung erkennt, schreibt Oi seine aktuelle Ansicht ri des neuen Preises nach L ein Eintrag der Form ⟨PriceView : i, j + 1, ri⟩. Ein zweiter Initiator init2 feuert, wenn mindestens k solcher PriceView-Einträge mit neuem Preis vorhanden sind Werte für den Index j + 1, die von verschiedenen Knoten erstellt wurden, haben sich auf L angesammelt. Dann init2 ruft eine Einstiegspunktlogik2 auf, um den Median ρ der ersten k neuen, gültigen Preisansichtswerte zu berechnen und schreibt einen neuen Wert ⟨NewPrice : j + 1, ρ⟩to L . (Operativ, Knoten können sich als designierte Autoren abwechseln.) Ein dritter Initiator init3 sucht nach NewPrice-Einträgen auf L. Immer wenn ein neuer Bericht vorliegt ⟨Neuer Preis: j, r⟩erscheint dort, es ruft eine Einstiegspunktlogik3 auf, die (j, r) an SC schiebt mithilfe eines Adapters. Wie bereits erwähnt, ähnelt eine ausführbare Datei in ihren Fähigkeiten einem smart contract. Abgesehen von der höheren Leistung unterscheidet er sich jedoch von einem typischen Main-Chain-Vertrag auf zwei wesentliche Arten: 1. Vertraulichkeit: Eine ausführbare Datei kann vertrauliche Berechnungen durchführen, d. h. ein geheimes Programm kann Klartexteingaben verarbeiten, oder ein veröffentlichtes Programm kann verarbeiten geheime Eingabedaten oder eine Kombination aus beidem. In einem einfachen Modell können geheime Daten Der Zugriff erfolgt über DON-Knoten, die Zwischenergebnisse verbergen und nur offenlegen verarbeitete und bereinigte Werte an MAINCHAIN. Es ist auch möglich, sensible Daten vor DONs selbst zu verbergen: DONs sollen solche Ansätze unterstützen als Mehrparteienberechnung, z. B. [42, 157], und vertrauenswürdige Ausführungsumgebungen (TEEs) [84, 133, 152, 229] für diesen Zweck.6 6Durch die Erweiterung ist es auch möglich, ausführbare Dateien selbst in Bezug auf DON-Knoten geheim zu halten. obwohl dies heute nur für nicht-triviale ausführbare Dateien, die TEEs verwenden, praktikabel ist.2. Unterstützende Rolle: Eine ausführbare Datei soll smart contracts auf einer Hauptdatei unterstützen Kette, anstatt sie zu ersetzen. Eine ausführbare Datei weist mehrere Einschränkungen auf: a smart contract nicht: (a) Vertrauensmodell: Eine ausführbare Datei arbeitet innerhalb des durch definierten Vertrauensmodells DON: Seine korrekte Ausführung hängt vom ehrlichen Verhalten von O. (A main) ab Die Kette kann jedoch einige Schutzmaßnahmen gegen DON Fehlverhalten bieten, z (siehe Abschnitt 7.3.) (b) Zugriff auf Vermögenswerte: Ein DON kann ein Konto auf einem blockchain kontrollieren – und somit Steuern Sie die darauf befindlichen Assets über einen Adapter. Aber ein DON kann nicht autoritär sein stellen Vermögenswerte dar, die auf einer Hauptkette erstellt wurden, z. B. Ether oder ERC20 tokens, seitdem Ihre heimische Kette führt die maßgeblichen Aufzeichnungen über ihre Eigentumsverhältnisse. (c) Lebenszyklus: DONs können absichtlich mit begrenzter Lebensdauer aufgestellt werden, z definiert durch On-Chain-Service-Level-Agreements zwischen DONs und den Eigentümern sich auf Verträge zu verlassen. Im Gegensatz dazu sollen Blockchains als solche funktionieren permanente Archivsysteme. Weitere Einzelheiten zur Berechnung von DON finden Sie in Anhang B.2. 3.3 Lagerung Als ausschussbasiertes System kann ein DON moderate Datenmengen dauerhaft speichern auf L zu viel geringeren Kosten als ein erlaubnisfreier blockchain. Zusätzlich über Adapter, DONs können auf externe dezentrale Systeme zur Datenspeicherung verweisen, z. B. Filecoin [85], und kann dadurch solche Systeme an smart contracts anschließen. Diese Option ist besonders attraktiv für Massendaten als Mittel zur Bewältigung des allgegenwärtigen Problems der „Aufblähung“ in blockchain Systeme. DONs können somit Daten lokal oder extern speichern, um sie in ihren speziell unterstützten Diensten zu verwenden. Ein DON kann diese Daten darüber hinaus vertraulich nutzen, Berechnung von Daten, die: (1) geheim über DON-Knoten hinweg geteilt oder darunter verschlüsselt sind Ein Schlüssel, der von DON-Knoten auf eine Weise verwaltet wird, die für sichere Mehrparteienberechnungen geeignet ist oder teilweise oder vollständig homomorphe Verschlüsselung; oder (2) durch eine vertrauenswürdige Ausführung geschützt Umgebung. Wir gehen davon aus, dass DONs ein einfaches gemeinsames Speicherverwaltungsmodell übernehmen werden Smart-Contract-Systeme: Eine ausführbare Datei darf nur in ihren eigenen Speicher schreiben. Ausführbare Dateien kann jedoch aus dem Speicher anderer ausführbarer Dateien lesen. Weitere Einzelheiten zur DON-Speicherung finden Sie in Anhang B.3. 3.4 Transaktionsausführungs-Framework (TEF) DONs sollen Verträge auf einer Hauptkette MAINCHAIN (oder auf mehreren Hauptketten) unterstützen. Das Transaction-Execution Framework (TEF), ausführlich besprochenin Abschnitt 6 ist ein allgemeiner Ansatz zur effizienten Ausführung eines Vertrags SC über MAINCHAIN und ein DON. Der TEF soll FSS und Layer-2 unterstützen Technologien – auf Wunsch auch gleichzeitig. Tatsächlich dürfte es als Hauptfahrzeug dienen für die Verwendung von FSS (und aus diesem Grund gehen wir in diesem Abschnitt nicht weiter auf FSS ein). Kurz gesagt, in TEF ein ursprünglicher Zielvertrag, der SC für MAINCHAIN entworfen oder entwickelt hat wird in einen Hybridvertrag umgestaltet. Dieses Refactoring führt dazu, dass die beiden zusammenarbeiten Teile des Hybridvertrags: ein MAINCHAIN-Vertrag SCa, auf den wir der Klarheit halber verweisen im Kontext von TEFs als Ankervertrag und ausführbarer Execs auf einem DON. Die Contract SCa verwahrt die Vermögenswerte der Benutzer, führt maßgebliche Statusübergänge durch und vieles mehr Bietet Leitplanken (siehe Abschnitt 7.3) gegen Ausfälle im DON. Die ausführbare Datei execs Sequenziert Transaktionen und stellt zugehörige oracle-Daten für sie bereit. Es kann gebündelt werden Transaktionen für SCa auf verschiedene Arten – z. B. mithilfe von auf Gültigkeitsnachweisen basierenden oder optimistische rollups, vertrauliche Ausführung durch den DON usw. Wir erwarten, Tools zu entwickeln, die es Entwicklern erleichtern, einen Vertrag aufzuteilen SC in einer Hochsprache in Teile der MAINCHAIN- und DON-Logik geschrieben, SCa und Führungskräfte bzw. Führungskräfte, die sicher und effizient komponieren. Verwendung von TEF zur Integration leistungsstarker Transaktionsschemata mit hoher Leistung oracles ist ein wesentlicher Bestandteil unseres Skalierungsansatzes oracle. 3.5 Mempool-Dienste Eine wichtige Funktion auf Anwendungsebene, die wir zur Unterstützung auf DONs bereitstellen möchten von FSS und TEF sind Mempool Services (MS). MS kann als Adapter betrachtet werden, aber eines mit erstklassigem Support. MS bietet Unterstützung für die Legacy-kompatible Transaktionsverarbeitung. In dieser Verwendung, MS Nimmt die für einen Zielvertrag vorgesehenen Transaktionen aus dem Mempool einer Hauptkette auf SC auf MAINCHAIN. MS übergibt diese Transaktionen dann an eine ausführbare Datei auf dem DON, wo sie in der gewünschten Weise verarbeitet werden. MS-Daten können vom DON verwendet werden. um Transaktionen zu erstellen, die dann vom DON oder direkt an SC übergeben werden können zu einem anderen Vertrag, der SC anruft. Beispielsweise kann der DON Transaktionen weiterleiten über MS gesammelt werden, oder es kann MS-Daten verwenden, um Gaspreise für Transaktionen festzulegen, an die es sendet HAUPTKETTE. Da es den Mempool überwacht, kann MS Transaktionen von Benutzern erhalten, die direkt mit SC interagieren. Somit können Benutzer weiterhin ihre Transaktionen generieren Legacy-Software, d. h. Anwendungen, die nichts von der Existenz von MS wissen und MS-konfiguriert sind Verträge. (In diesem Fall muss SC geändert werden, um die ursprünglichen Transaktionen zu ignorieren und Akzeptieren Sie nur diejenigen, die vom MS verarbeitet wurden, um eine Doppelverarbeitung zu vermeiden.) Zur Verwendung mit einem Zielvertrag SC, MS kann mit FSS und/oder dem TEF verwendet werden.3.6 Sprungbrett: Vorhandene Chainlink-Fähigkeiten 3.6.1 Off-Chain-Reporting (OCR) Off-Chain Reporting (OCR) [60] ist ein Mechanismus in Chainlink für die oracle Berichtsaggregation und -übertragung an einen vertrauenden Vertrags-SC. Kürzlich zum Preis von Chainlink bereitgestellt Feed-Netzwerke stellt es einen ersten Schritt auf dem Weg zu vollständigen DONs dar. Im Kern ist OCR ein BFT-Protokoll, das für den teilweise synchronen Betrieb konzipiert ist Netzwerk. Es stellt willkürlich Lebendigkeit und Korrektheit bei Vorliegen von f < n/3 sicher fehlerhafte Knoten, die die Eigenschaften der byzantinischen zuverlässigen Übertragung garantieren, dies ist jedoch nicht der Fall ein vollständiges BFT-Konsensprotokoll. Knoten verwalten keine Nachrichtenprotokolle konsistent im Sinne der Darstellung eines Hauptbuchs, das in allen Ansichten identisch ist, und der Protokollführer kann zweideutige Aussagen machen, ohne die Sicherheit zu verletzen. OCR ist derzeit für einen bestimmten Nachrichtentyp konzipiert: medianisierte Aggregation von (mindestens 2f +1) Werte, die von teilnehmenden Knoten gemeldet werden. Es bietet eine wichtige Sicherheit die Berichte, die es für SC ausgibt, sogenannte attestierte Berichte: Der Medianwert in einem attestierten Der Bericht ist gleich oder liegt zwischen den von zwei ehrlichen Knoten gemeldeten Werten. Diese Eigenschaft ist die wichtigste Sicherheitsbedingung für OCR. Der Anführer kann einen gewissen Einfluss auf den Median haben Wert in einem beglaubigten Gutachten, jedoch nur unter dieser Richtigkeitsbedingung. OCR kann kann auf Nachrichtentypen erweitert werden, die Werte auf unterschiedliche Weise aggregieren. Während die Liveness- und Korrektheitsziele des Chainlink-Netzwerks heute nicht erforderlich sind Damit OCR ein vollwertiges Konsensprotokoll ist, muss OCR einige zusätzliche Funktionalitäten bereitstellen, die in herkömmlichen BFT-Protokollen nicht vorhanden sind, insbesondere: 1. Alles-oder-Nichts-Berichtsübertragung außerhalb der Kette: OCR stellt sicher, dass ein beglaubigter Bericht vorliegt wird schnell allen ehrlichen Knoten oder keinem von ihnen zur Verfügung gestellt. Das ist eine Fairness Eigenschaft, die dazu beiträgt, sicherzustellen, dass ehrliche Knoten die Möglichkeit haben, sich zu beteiligen in beglaubigter Berichtsübermittlung. 2. Zuverlässige Übertragung: OCR gewährleistet, auch bei fehlerhafter oder böswilliger Übertragung Knoten, dass alle OCR-Berichte und -Nachrichten innerhalb eines bestimmten Zeitraums an SC übermittelt werden, vordefiniertes Zeitintervall. Dies ist eine Liveness-Eigenschaft. 3. Vertragsbasierte Vertrauensminimierung: SC filtert potenziell fehlerhafte OCR-generierte Berichte heraus, z. B. wenn ihre gemeldeten Werte erheblich von anderen abweichen kürzlich erhaltene. Dies ist eine Form der Durchsetzung der Korrektheit außerhalb des Protokolls. Alle drei dieser Eigenschaften werden in DONs eine natürliche Rolle spielen. Die Off-Chain-Übertragung „Alles oder Nichts“ (DON) ist ein wichtiger Baustein für kryptoökonomische Absicherungen um eine zuverlässige Übertragung, die wiederum eine wesentliche Adaptereigenschaft darstellt. Vertrauen Die Minimierung in SC ist eine Art Leitplanke, wie in Abschnitt 7.3 erläutert. OCR bietet auch eine Grundlage für den operativen Einsatz und die Verfeinerung von BFT-Protokollen in den oracle-Netzwerken von Chainlink und damit, wie oben erwähnt, einen Weg zur Vollendung Funktionalität von DONs.3.6.2 DECO und Town Crier DECO [234] und Town Crier [233] sind zwei verwandte Technologien, die derzeit entwickelt werden entwickelt in Chainlink Netzwerken. Heutzutage ermöglichen die meisten Webserver Benutzern die Verbindung über einen sicheren Kanal mithilfe eines Protokolls namens Transport Layer Security (TLS) [94]. (HTTPS bezeichnet eine Variante von HTTP, die ist mit TLS aktiviert, d. h. URLs mit dem Präfix „https“ weisen auf die Verwendung von TLS aus Sicherheitsgründen hin.) Die meisten TLS-fähigen Server haben jedoch eine bemerkenswerte Einschränkung: Sie signieren nicht digital Daten. Folglich kann ein Benutzer oder Prüfer die Daten, die er von einem Server erhält, nicht präsentieren an einen Dritten oder Verifizierer, z. B. oracle oder smart contract, auf eine Weise weiter, die dies gewährleistet die Authentizität der Daten. Selbst wenn ein Server Daten digital signieren würde, bleibt ein Vertraulichkeitsproblem bestehen. Ein Prüfer möchte möglicherweise vertrauliche Daten schwärzen oder ändern, bevor er sie einem präsentiert Prüfer. Digitale Signaturen dienen jedoch speziell dazu, geänderte Daten ungültig zu machen. Sie verhindern somit, dass ein Prüfer vertrauliche Änderungen vornimmt zu Daten. (Weitere Informationen finden Sie in Abschnitt 7.1.) DECO und Town Crier sollen es einem Prüfer ermöglichen, Daten aus einem Web abzurufen Server und legen Sie es einem Verifizierer auf eine Weise vor, die Integrität und Vertraulichkeit gewährleistet. Die beiden Systeme wahren die Integrität in dem Sinne, dass sie sicherstellen, dass die von ihnen präsentierten Daten gewährleistet sind Der Prüfer für den Verifizierer stammt authentisch vom Zielserver. Sie unterstützen Vertraulichkeit in dem Sinne, dass es dem Prüfer gestattet ist, Daten zu redigieren oder zu ändern (während er noch … Wahrung der Integrität). Ein wesentliches Merkmal beider Systeme ist, dass sie keine Änderungen an a erfordern Ziel-Webserver. Sie können mit jedem vorhandenen TLS-fähigen Server betrieben werden. Tatsächlich, Sie sind für den Server transparent: Aus der Sicht des Servers ist dies der Nachweiserbringer Herstellen einer gewöhnlichen Verbindung. Die beiden Systeme verfolgen ähnliche Ziele, unterscheiden sich jedoch in ihren Vertrauensmodellen und Implementierungen, wie wir nun kurz erläutern. DECO nutzt grundsätzlich kryptografische Protokolle, um seine Integrität zu erreichen und Vertraulichkeitseigenschaften. Beim Einrichten einer Sitzung mit einem Zielserver mithilfe von DECO beteiligt sich der Nachweiserbringer gleichzeitig an einem interaktiven Protokoll mit dem Prüfer. Mit diesem Protokoll kann der Nachweiserbringer dem Verifizierer nachweisen, dass er empfangen hat ein bestimmtes Datenelement D vom Server während seiner aktuellen Sitzung. Der Prüfer kann Alternativ können Sie dem Verifizierer einen wissensfreien Beweis für eine Eigenschaft von D vorlegen und somit D nicht direkt offenbaren. Bei einer typischen Verwendung von DECO kann ein Benutzer oder ein einzelner Knoten Daten D aus einem privaten exportieren Sitzung mit einem Webserver an alle Knoten in einem DON. Dadurch kann der volle DON die Authentizität von D (oder einer von D durch einen wissensfreien Beweis abgeleiteten Tatsache) bescheinigen. Zusätzlich zu den Beispielanwendungen, die weiter unten in diesem Dokument aufgeführt werden, kann diese Funktion genutzt werden Wird verwendet, um den hochintegrierten Zugriff auf eine Datenquelle durch einen DON zu verstärken. Auch wenn nur ein Knoten hat direkten Zugriff auf eine Datenquelle – beispielsweise aufgrund einer Exklusivvereinbarung mit ein Datenlieferant – es bleibt dem gesamten DON möglich, die Richtigkeit zu bestätigenVon diesem Knoten ausgegebene Berichte. Town Crier setzt auf den Einsatz einer Trusted Execution Environment (TEE) wie Intel SGX. Kurz gesagt fungiert ein TEE als eine Art Blackbox, die Anwendungen in einem ausführt manipulationssicher und vertraulich. Im Prinzip ist sogar der Besitzer des Hosts auf dem Das ausgeführte TEE kann weder eine TEE-geschützte Anwendung (unerkennbar) verändern noch Zeigen Sie den Status der Anwendung an, der möglicherweise geheime Daten enthält. Town Crier kann alle Funktionen von DECO und mehr erreichen. DECO beschränkt den Prüfer auf die Interaktion mit einem einzelnen Prüfer. Im Gegensatz dazu ermöglicht Town Crier ein Prüfer, der einen öffentlich überprüfbaren Beweis für die von einem Zielserver abgerufenen Daten D erstellt, d. h. ein Beweis, den jeder, sogar ein smart contract, direkt überprüfen kann. Town Crier kann auch Geheimnisse (z. B. Benutzeranmeldeinformationen) sicher erfassen und nutzen. Die größte Einschränkung von Town Crier ist die Abhängigkeit von TEEs. Produktions-TEEs haben Es wurde kürzlich gezeigt, dass die Technologie eine Reihe schwerwiegender Schwachstellen aufweist, obwohl die Technologie noch in den Kinderschuhen steckt und zweifellos ausgereift sein wird. Siehe Anhänge B.2.1 und B.2.2 für weitere Diskussion über TEEs. Einige Beispielanwendungen von DECO und Town Crier finden Sie in den Abschnitten 4.3 und 4.5 und 9.4.3 und Anhang C.1. 3.6.3 Bestehende On-Chain-Dienste Chainlink Chainlink oracle Netzwerke bieten eine Reihe wichtiger Dienste in einer Vielzahl von Bereichen an blockchains und andere dezentrale Systeme heute. Weitere Entwicklung wie beschrieben In diesem Whitepaper werden diese vorhandenen Dienste mit zusätzlichen Funktionen ausgestattet und erreichen. Drei Beispiele sind: Datenfeeds: Heutzutage verlässt sich die Mehrheit der Chainlink-Benutzer auf smart contracts Nutzung von Datenfeeds. Dabei handelt es sich um Berichte über den aktuellen Wert zentraler Daten an seriöse Off-Chain-Quellen. Preis-Feeds sind beispielsweise Feeds, die die Preise melden von Vermögenswerten – Kryptowährungen, Rohstoffe, Devisen, Indizes, Aktien usw. – laut Austausch oder Datenaggregationsdienste. Schon heute tragen solche Feeds dazu bei, Milliardenbeträge zu sichern von Dollar an On-Chain-Wert durch ihre Verwendung in DeFi Systemen wie Aave [147] und Synthetix [208]. Weitere Beispiele für Chainlink-Datenfeeds sind Wetterdaten für unter anderem parametrische Ernteversicherung [75] und Wahldaten [93]. Der Einsatz von DONs und anderen in diesem Dokument beschriebenen Technologien wird die Bereitstellung von Datenfeeds in Chainlink-Netzwerken in vielerlei Hinsicht verbessern, darunter: • Skalierung: OCR und anschließend DONs zielen darauf ab, die Skalierung von Chainlink-Diensten zu ermöglichen dramatisch über die vielen blockchains, die sie unterstützen. Wir erwarten zum Beispiel dass DONs dazu beitragen wird, die Anzahl der von Knoten bereitgestellten Datenfeeds zu erhöhen Chainlink von 100 bis 1000 und darüber hinaus. Eine solche Skalierung hilft dem Chainlink Das Ökosystem erreicht sein Ziel, für smart contracts relevante Daten umfassend bereitzustellen und bestehende und zukünftige Bedürfnisse sowohl zu erfüllen als auch zu antizipieren.• Erhöhte Sicherheit: Durch die Speicherung von Zwischenberichten behalten DONs Datensätze bei von Knotenverhalten für eine hochpräzise Überwachung und Messung ihrer Leistung und Genauigkeit, was eine starke empirische Grundlage für Reputationssysteme ermöglicht für Chainlink Knoten. FSS und TEF ermöglichen die Einbindung von Preis-Feeds mit Transaktionsdaten auf flexible Weise umgehen, um Angriffe wie Front-Running zu verhindern. (Explizit) staking wird den bestehenden kryptoökonomischen Schutz des Wertpapiers stärken von Datenfeeds. • Feed-Agilität: Als blockchain-agnostische Systeme (im weiteren Sinne verbraucheragnostische Systeme) können DONs die Bereitstellung von Daten-Feeds für eine Vielzahl erleichtern von sich verlassenden Systemen. Ein einzelner DON kann einen bestimmten Feed gleichzeitig an einen Satz senden verschiedener blockchains, wodurch die Notwendigkeit von oracle-Netzwerken pro Kette entfällt und Ermöglicht die schnelle Bereitstellung vorhandener Feeds auf neuen blockchains und zusätzlicher Feeds über aktuell bediente blockchains. • Vertraulichkeit: Die Möglichkeit, allgemeine Berechnungen in einem DON durchzuführen, ermöglicht die Durchführung von Berechnungen für sensible Daten außerhalb der Kette und nicht in der Kette Belichtung. Darüber hinaus ist es mit DECO oder Town Crier möglich, dies zu erreichen noch stärkere Vertraulichkeit, die die Erstellung von Berichten auf der Grundlage von Daten ermöglicht, die nicht vertraulich sind sogar DON-Knoten ausgesetzt. Beispiele finden Sie in Abschnitt 4.3 und Abschnitt 4.5. Überprüfbare Zufallsfunktionen (VRFs): Mehrere Arten von DApps erfordern eine nachweislich korrekte Zufallsquelle, um die Überprüfung ihres eigenen fairen Betriebs zu ermöglichen. Ein Beispiel sind nicht fungible Token (NFTs). Die Seltenheit von NFT-Features in Aavegotchi [23] und Axie Infinity [35] wird durch Chainlink VRF bestimmt, ebenso wie die Verteilung von NFTs mittels losbasierter Ziehungen in Ether Cards [102]; die große Vielfalt an Gaming-DApps, deren Ergebnisse zufällig sind; und unkonventionelle Finanzinstrumente, z. B. verlustfreie Sparspiele wie PoolTogether [89], denen Gelder zugewiesen werden zufällige Gewinner. Andere blockchain- und Nicht-blockchain-Anwendungen erfordern ebenfalls Sicherheit Quellen der Zufälligkeit, einschließlich der Auswahl von Komitees für dezentrale Systeme und der Durchführung von Lotterien. Während der Block hashes als Quelle unvorhersehbarer Zufälligkeit dienen kann, sind sie anfällig für Manipulationen durch gegnerische Miner (und in gewissem Maße auch durch Benutzer, die Daten einreichen). Transaktionen). Chainlink VRF [78] bietet eine wesentlich sicherere Alternative. Ein oracle verfügt über ein zugehöriges privates/öffentliches Schlüsselpaar (sk, pk), dessen privater Schlüssel außerhalb der Kette verwaltet wird und dessen öffentlicher Schlüssel pk veröffentlicht wird. Um einen Zufallswert auszugeben, it wendet sk auf einen unvorhersehbaren Seed x an, der durch einen vertrauenden Vertrag bereitgestellt wird (z. B. einen Block hash und DApp-spezifische Parameter) unter Verwendung einer Funktion F, was y = Fsk(x) zusammen mit a ergibt Beweis der Richtigkeit. (VRF finden Sie unter [180], verfügbar unter Chainlink.) Was macht ein VRF-überprüfbar ist die Tatsache, dass es mit Kenntnis von pk möglich ist, die Korrektheit des Beweises und damit von y zu überprüfen. Der Wert y ist daher für an unvorhersehbar Gegner, der x nicht vorhersagen oder sk nicht lernen kann und für den Dienst nicht manipulierbar ist.Chainlink VRF kann nur als eine aus einer Familie von Anwendungen angesehen werden, die die Verwahrung privater Schlüssel außerhalb der Kette beinhalten. Allgemeiner gesagt können DONs sichere, dezentrale Speicherung einzelner Schlüssel für Anwendungen und/oder Benutzer und kombinieren diese Fähigkeit mit verallgemeinerter Berechnung. Das Ergebnis ist eine Vielzahl von Anwendungen, von Wir geben in diesem Artikel einige Beispiele, einschließlich der Schlüsselverwaltung für Proof of Reserven (siehe Abschnitt 4.1) und für die dezentralen Anmeldeinformationen der Benutzer (und andere digitale Vermögenswerte) (siehe Abschnitt 4.3). Bewahrer: Chainlink Keepers [87] ermöglichen Entwicklern das Schreiben von Code für die Dezentralisierung Ausführung von Off-Chain-Jobs, im Allgemeinen, um die Ausführung von smart contracts auszulösen. Vor dem Aufkommen von Keepers war es für Entwickler üblich, solche Dinge außerhalb der Kette zu betreiben Logik selbst, wodurch zentralisierte Fehlerquellen entstehen (und erheblicher doppelter Entwicklungsaufwand entsteht). Keepers bieten stattdessen ein benutzerfreundliches Framework für dezentrales Outsourcing dieser Vorgänge, was kürzere Entwicklungszyklen ermöglicht und starke Gewährleistung der Lebendigkeit und anderer Sicherheitseigenschaften. Halter können jeden unterstützen unterschiedlichster auslösender Ziele, darunter preisabhängige Abwicklung von Krediten bzw Durchführung von Finanztransaktionen, zeitabhängige Auslösung von Airdrops oder Zahlungen in Systemen mit Ertragsernte usw. Im Rahmen von DON können Initiatoren in mehrfacher Hinsicht als eine Verallgemeinerung von Bewahrern betrachtet werden. Initiatoren können Adapter verwenden und somit a nutzen Modularisierte Bibliothek von Schnittstellen zu On-Chain- und Off-Chain-Systemen, die eine schnelle Bereitstellung ermöglicht Entwicklung sicherer, anspruchsvoller Funktionalität. Initiatoren initiieren die Berechnung ausführbare Dateien, die selbst die volle Vielseitigkeit von DONs bieten und so die Breite ermöglichen Eine Reihe dezentraler Dienste, die wir in diesem Dokument für On-Chain- und Off-Chain-Anwendungen vorstellen. 3.6.4 Knotenreputation/Leistungsverlauf Das bestehende Ökosystem Chainlink dokumentiert nativ die Leistungsverläufe von beitragende Knoten in der Kette. Diese Funktion hat zu einer Sammlung von Reputations-orientierten Ressourcen geführt, die Leistungsdaten von Einzelpersonen erfassen, filtern und visualisieren Knotenbetreiber und Datenfeeds. Benutzer können auf diese Ressourcen verweisen, um sich zu informieren Entscheidungen bei der Knotenauswahl zu treffen und den Betrieb bestehender Netzwerke zu überwachen. Ähnliche Funktionen helfen Benutzern bei der Auswahl von DONs. Heutige erlaubnislose Marktplätze wie Market.link erlauben beispielsweise Node Betreiber müssen ihre oracle-Dienste auflisten und ihre Identität außerhalb der Kette bestätigen Dienste wie Keybase [4], die das Profil eines Knotens in Chainlink an seinen binden bestehende Domainnamen und Social-Media-Konten des Eigentümers. Darüber hinaus Leistung Analysetools, wie sie beispielsweise auf Market.link und Reputation.link verfügbar sind, ermöglichen dies Benutzer können Statistiken über die historische Leistung einzelner Knoten anzeigen, einschließlich ihrer durchschnittliche Antwortlatenz, die Abweichung der Werte in ihren Berichten von den Konsenswerten in der Kette weitergeleitet, generierte Einnahmen, erfüllte Aufträge und mehr. Diese Analysetools auch Ermöglichen Sie Benutzern, die Akzeptanz verschiedener oracle-Netzwerke durch andere Benutzer zu verfolgen, eine Form vonimplizite Unterstützung der Knoten, die solche Netzwerke sichern. Das Ergebnis ist ein flaches „Netz aus Vertrauen“, bei dem durch die Nutzung bestimmter Knoten hochwertige dezentrale Anwendungen entstehen ein Signal ihres Vertrauens in diese Knoten, die andere Benutzer beobachten und in ihre einbeziehen können eigene Knotenauswahlentscheidungen. Mit DONs (und zunächst mit OCR) kommt es zu einer Verschiebung in der Transaktionsverarbeitung und Vertragsaktivitäten im Allgemeinen außerhalb der Kette. Ein dezentrales Modell für den Aufzeichnungsknoten Die Leistung bleibt innerhalb des DON selbst möglich. In der Tat, die hohe Leistung und die Datenkapazität von DONs ermöglichen die feinkörnige Erstellung von Datensätzen Auf diese Weise können auch dezentrale Berechnungen für diese Datensätze durchgeführt werden, wodurch vertrauenswürdige Zusammenfassungen entstehen, die von Reputationsdiensten genutzt und mit Prüfpunkten versehen werden können HAUPTKETTE. Während es grundsätzlich möglich ist, dass ein DON das Verhalten der einzelnen Knoten falsch darstellt, wenn ein großer Teil der Knoten beschädigt ist, stellen wir fest, dass das Kollektiv Die Leistung eines DON selbst bei der Bereitstellung von On-Chain-Daten ist auf MAINCHAIN sichtbar und kann daher nicht falsch dargestellt werden. Darüber hinaus planen wir, Mechanismen zu erforschen, die Anreize für eine genaue interne Berichterstattung über Knotenverhalten in einem DON. Beispielsweise durch die Meldung der Teilmenge der leistungsstarken Knoten, die am schnellsten beitragende Daten zurückgeben Bei einem in der Kette weitergeleiteten Bericht schafft ein DON einen Anreiz für Knoten, Fehler anzufechten Berichte: Das fälschliche Einbeziehen von Knoten in diese Teilmenge bedeutet, dass Knoten fälschlicherweise ausgeschlossen werden das hätte einbezogen werden müssen und sie daher unwirksam bestraft. Wiederholte Meldefehler durch einen DON würden auch einen Anreiz für ehrliche Knoten schaffen, den zu verlassen DON. Dezentrale Erfassung genauer Leistungsverläufe und deren Folge Fähigkeit der Benutzer, leistungsstarke Knoten zu identifizieren und Knotenbetreibern den Aufbau zu ermöglichen Reputationen sind wichtige Unterscheidungsmerkmale des Chainlink-Ökosystems. Wir Zeigen Sie in Abschnitt 9, wie wir über sie als Schlüsselelement einer rigorosen Analyse nachdenken können umfassende Sicht auf die wirtschaftliche Sicherheit, die DONs bietet.

Dezentrale Dienste, ermöglicht durch Decentralized

Oracle-Netzwerke Um die Vielseitigkeit von DONs zu veranschaulichen und wie sie eine Vielzahl neuer Dienste ermöglichen, In diesem Abschnitt stellen wir fünf Beispiele für DON-basierte Anwendungen vor und beschreiben die Hybridverträge, die diese realisieren: (1) Proof of Reserves, eine Form des kettenübergreifenden Dienstes; (2) Anbindung an Unternehmens-/Altsysteme, d. h. Erstellung einer Middleware-basierten Lösung Abstraktionsschicht, die die Entwicklung von blockchain-Anwendungen mit minimalem Aufwand ermöglicht blockchain-spezifischer Code oder Fachwissen; (3) Dezentrale Identität, Tools, die Benutzern dies ermöglichen eigene Ausweisdokumente und Anmeldeinformationen beschaffen und verwalten; (4) Vorrangige Kanäle, ein Dienst, der die rechtzeitige Einbeziehung kritischer Infrastrukturtransaktionen gewährleistet (z. B. oracle Berichte) auf einem blockchain; und (5) die Vertraulichkeit wahrender DeFi, d. h. finanzieller Art smart contracts, die die sensiblen Daten der teilnehmenden Parteien verbergen. Hier, wir

Verwenden Sie SC, um den MAINCHAIN-Teil eines Hybridvertrags zu bezeichnen und den DON zu beschreiben. Komponente separat oder in Form einer ausführbaren Datei exec. 4.1 Nachweis der Reserven Für viele Anwendungen ist es nützlich, den Status zwischen oder zwischen blockchains weiterzuleiten. A Eine beliebte Anwendung solcher Dienste ist das Verpacken von Kryptowährungen. Eingewickelte Münzen wie z als WBTC [15] werden zu einem beliebten Vermögenswert im dezentralen Finanzwesen (DeFi). Sie Dazu gehört die Hinterlegung des „verpackten“ Sicherungswerts an seiner Quelle blockchain MAINCHAIN(1) und Erstellen eines entsprechenden token auf einem anderen Ziel blockchain MAINCHAIN(2). Beispielsweise ist WBTC ein ERC20 token auf dem entsprechenden Ethereum blockchain an BTC am Bitcoin blockchain. Da Verträge auf MAINCHAIN(2) keinen direkten Einblick in MAINCHAIN(1) haben, Sie müssen sich explizit oder implizit auf einen oracle verlassen, um über Ablagerungen des Eingewickelten zu berichten Vermögenswert in einem smart contract, wodurch ein sogenannter Reservennachweis entsteht. In WBTC [15], zum Beispiel hält die Depotbank BitGo BTC und gibt WBTC aus, mit dem Chainlink Netzwerk, das Reservenachweise bereitstellt [76]. Ein DON kann selbst einen Reservenachweis liefern. Mit einem DON ist es jedoch möglich weiter gehen. Ein DON kann Geheimnisse verwalten und durch die Verwendung geeigneter Adapter kann auf jedem gewünschten blockchain Transaktionen durchführen. Folglich ist es möglich, dass DON agiert als einer unter mehreren Verwaltern – oder sogar als alleiniger, dezentraler Verwalter – für ein verpackter Vermögenswert. DONs können dadurch als Plattform zur Verbesserung der Sicherheit dienen bestehende Dienste, die Reservenachweise verwenden. Angenommen, MAINCHAIN(1) ist Bitcoin und MAINCHAIN(2) ist Ethereum. Auf MAINCHAIN(2) gibt ein Vertrags-SC tokens aus, die verpackte BTC darstellen. Der DON steuert eine BTC-Adresse addr(1) DON. Um BTC zu verpacken, sendet ein Benutzer U X BTC von Adresse(1) U zu addr(1) DON zusammen mit einer MAINCHAIN(2)-Adresse addr(2) Du. Die DON-Monitore Adresse(1) DON über einen Adapter zu MAINCHAIN(1). Sobald die Einzahlung von U festgestellt wird und eine Bestätigung mit ausreichend hoher Wahrscheinlichkeit vorliegt, sendet es über einen Adapter eine Nachricht an SC HAUPTKETTE(2). Diese Nachricht weist SC an, X tokens für addr(2) zu prägen. Du. Damit U X tokens freigibt, geschieht das Gegenteil. Auf MAINCHAIN(1) jedoch Adresse(1) DON sendet X BTC an Adresse (1) U (oder an eine andere Adresse, wenn dies vom Benutzer gewünscht wird). Diese Protokolle können natürlich angepasst werden, um mit Börsen statt direkt zu funktionieren mit Benutzern. 4.2 Anbindung an Unternehmens-/Altsysteme DONs können als Brücken zwischen und zwischen blockchains dienen, wie im Beispiel von Proof von Reserven, aber ein anderes Ziel besteht darin, dass sie als bidirektionale Brücken zwischen ihnen fungieren blockchains und Legacy-Systeme [176] oder blockchain-ähnliche Systeme wie die Zentralbank digitale Währungen [30]. Unternehmen stehen bei der Verbindung ihrer bestehenden Systeme vor einer Reihe von Herausforderungen Prozesse an dezentrale Systeme, darunter:• Blockchain-Agilität: Blockchain-Systeme ändern sich schnell. Ein Unternehmen kann mit dem schnellen neuen Erscheinungsbild oder der zunehmenden Beliebtheit von blockchains konfrontiert werden Gegenparteien möchten Transaktionen durchführen, für die das Unternehmen jedoch keine hat Unterstützung in der bestehenden Infrastruktur. Im Allgemeinen macht die Dynamik von blockchains aus Für einzelne Unternehmen ist es schwierig, mit dem gesamten Ökosystem Schritt zu halten. • Blockchain-spezifische Entwicklungsressourcen: Für viele Organisationen ist es schwierig, hochmodernes blockchain-Fachwissen einzustellen oder zu fördern, insbesondere angesichts der Herausforderung der Agilität. • Verwaltung privater Schlüssel: Die Verwaltung privater Schlüssel für blockchains oder Kryptowährungen erfordert operatives Fachwissen, das sich von dem der herkömmlichen Cybersicherheit unterscheidet Praktiken und für viele Unternehmen nicht verfügbar. • Vertraulichkeit: Unternehmen scheuen davor zurück, ihre sensiblen und geschützten Daten preiszugeben Daten zur Kette. Um die ersten drei dieser Schwierigkeiten zu lösen, können Entwickler einfach einen DON verwenden. als sichere Middleware-Schicht, um Unternehmenssystemen das Lesen oder Schreiben zu ermöglichen blockchains. Der DON kann detaillierte technische Überlegungen abstrahieren, z Gasdynamik, Kettenreorganisation usw. sowohl für Entwickler als auch für Benutzer. Von Ein DON bietet somit eine optimierte blockchain-Schnittstelle zu Unternehmenssystemen Vereinfachen Sie die Entwicklung von blockchain-fähigen Unternehmensanwendungen erheblich und entlasten Sie Unternehmen von der Last, blockchain-spezifische Entwicklungsressourcen zu erwerben oder zu entwickeln. Eine solche Verwendung von DONs ist besonders attraktiv, da sie Unternehmensentwicklern dies ermöglicht Erstellen Sie Smart-Contract-Anwendungen, die weitgehend blockchain agnostisch sind. Infolgedessen ist die größer ist die Menge der blockchains, für die ein DON als Middleware instrumentiert ist Größer ist die Menge der blockchains, auf die Unternehmensbenutzer problemlos zugreifen können. Entwickler kann Anwendungen von vorhandenen blockchains mit minimalen Änderungen auf neue portieren zu ihren intern entwickelten Anwendungen. Um das zusätzliche Problem der Vertraulichkeit anzugehen, können sich Entwickler an die wenden Tools, die wir in diesem Dokument vorstellen und voraussichtlich zur Unterstützung von DON-Anwendungen eingesetzt werden. Dazu gehören DECO und Town Crier Abschnitt 3.6.2 sowie die Wahrung der Vertraulichkeit API-Änderungen, die in Abschnitt 7.1.2 besprochen werden, und eine Reihe anwendungsspezifischer Ansätze, die im Rest dieses Abschnitts behandelt werden. Diese DON-Systeme können Folgendes bieten Hochintegrierte On-Chain-Bescheinigungen über den Zustand des Unternehmenssystems, ohne diese preiszugeben sensible Unternehmensquelldaten in der Kette. 4.3 Dezentrale Identität Dezentrale Identität ist ein allgemeiner Begriff für die Vorstellung, dass Benutzer dazu in der Lage sein sollten Erhalten und verwalten Sie Ihre eigenen Anmeldeinformationen, anstatt sich dabei auf Dritte zu verlassen also. Dezentrale Anmeldeinformationen sind Bescheinigungen über Eigenschaften oder Behauptungen des Inhabers.die oft als Ansprüche bezeichnet werden. Anmeldeinformationen werden von Entitäten digital signiert, oft genannt Emittenten, die Ansprüche verbindlich den Nutzern zuordnen können. In den meisten vorgeschlagenen Systemen Ansprüche sind mit einem Decentralized Identifier (DID) verknüpft, einem universellen Identifikator für ein bestimmter Benutzer. Anmeldeinformationen sind an einen öffentlichen Schlüssel gebunden, dessen privaten Schlüssel der Benutzer besitzt. Der Nutzer kann somit mit seinem privaten Schlüssel den Besitz einer Forderung nachweisen. So visionär die dezentrale Identität auch ist, bestehende und vorgeschlagene Systeme, z. B. [14, 92, 129, 216] haben drei schwerwiegende Einschränkungen: • Mangelnde Legacy-Kompatibilität: Bestehende dezentrale Identitätssysteme basieren auf a Eine Gemeinschaft von Behörden, sogenannte Issuer, zur Erstellung von DID-Berechtigungsnachweisen. Weil Bestehende Webdienste signieren Daten im Allgemeinen nicht digital, Emittenten müssen gestartet werden als Sonderanlagen. Weil es keinen Anreiz gibt, dies ohne eine zu tun Bei einem dezentralen Identitätsökosystem entsteht ein Henne-Ei-Problem. In anderen Mit anderen Worten: Es ist unklar, wie ein Emittenten-Ökosystem aufgebaut werden kann. • Undurchführbare Schlüsselverwaltung: Dezentrale Identitätssysteme erfordern dies von den Benutzern Private Schlüssel verwalten, wie die Erfahrung mit Kryptowährungen gezeigt hat eine undurchführbare Pflicht sein. Es wird geschätzt, dass es etwa 4.000.000 Bitcoin waren aufgrund von Fehlern bei der Schlüsselverwaltung [194] für immer verloren und viele Benutzer speichern sie Krypto-Assets mit Börsen [193], wodurch die Dezentralisierung untergraben wird. • Mangel an Sybil-Widerstand, der die Privatsphäre schützt: Eine grundlegende Sicherheitsanforderung für Anwendungen wie Abstimmungen, faire Zuteilung von tokens während token-Verkäufen usw. ist dies Benutzer können nicht mehrere Identitäten geltend machen. Bestehende dezentrale Identitätsvorschläge erfordern, dass Benutzer ihre reale Identität preisgeben, um dies zu erreichen Sybil-Widerstand, wodurch wichtige Datenschutzgarantien untergraben werden. Es ist möglich, diese Probleme durch die Kombination eines Knotenkomitees anzugehen Durchführen verteilter Berechnungen innerhalb eines DON und die Verwendung von Tools wie DECO oder Town Crier, wie in einem System namens CanDID [160] gezeigt. DECO oder Town Crier können von Natur aus bestehende Webdienste ohne Änderungen umwandeln in vertrauliche Aussteller von Berechtigungsnachweisen. Sie ermöglichen einem DON den relevanten Export Daten für diesen Zweck in einen Berechtigungsnachweis umwandeln und gleichzeitig sensible Daten verbergen, die dies nicht sollten erscheinen im Ausweis. Darüber hinaus soll die Schlüsselwiederherstellung für Benutzer erleichtert und so die Schlüsselverwaltung angegangen werden Problem: Ein DON kann es Benutzern ermöglichen, private Schlüssel in geheimer, gemeinsam genutzter Form zu speichern. Benutzer können Stellen Sie ihre Schlüssel wieder her, indem Sie sie den Knoten im DON beweisen – auf ähnliche Weise mithilfe von Town Crier oder DECO – eine Möglichkeit, sich bei Konten bei einer Reihe vorgegebener Webanbieter anzumelden (z. B. Twitter, Google, Facebook). Der Vorteil der Verwendung von Town Crier oder DECO im Gegensatz zu OAUTH steht für die Privatsphäre der Benutzer. Diese beiden Tools ermöglichen es einem Benutzer, die Offenlegung gegenüber dem DON zu vermeiden. eine Web-Provider-Kennung, aus der häufig reale Identitäten abgeleitet werden können. Um schließlich Sybil-Resistenz bereitzustellen, wie in [160] gezeigt, ist es für einen DON möglich Führen Sie eine datenschutzschonende Transformation eindeutiger realer Identifikatoren für Benutzer durch (z. B. Sozialversicherungsnummern (SSNs)) bei der Benutzerregistrierung in On-Chain-Identifikatoren umgewandelt.Dadurch kann das System Doppelanmeldungen erkennen, ohne dass sensible Daten wie z.B SSNs werden einzelnen DON-Knoten offengelegt.7 Ein DON kann jeden dieser Dienste im Namen einer externen dezentralen Identität bereitstellen Systeme auf erlaubnislosen oder berechtigten blockchains, z. B. Instanzen von Hyperledger Indy [129]. Beispielanwendung: KYC: Eine dezentrale Identität ist ein vielversprechendes Mittel dazu Optimieren Sie die Anforderungen für Finanzanwendungen auf blockchains und verbessern Sie gleichzeitig die Benutzerfreundlichkeit Privatsphäre. Zwei Herausforderungen, bei deren Bewältigung wir helfen können, sind Akkreditierungs- und Compliance-Verpflichtungen im Rahmen der Anti-Geldwäsche-/Know-Your-Customer-Vorschriften (AML/KYC). Die AML-Vorschriften in vielen Ländern verlangen von Finanzinstituten (und anderen Unternehmen), die Identität von Einzelpersonen und Unternehmen, mit denen sie zusammenarbeiten, festzustellen und zu überprüfen Sie führen Transaktionen durch. KYC ist ein Bestandteil der Geschäftstätigkeit eines Finanzinstituts Eine umfassendere AML-Richtlinie umfasst in der Regel unter anderem auch die Überwachung des Benutzerverhaltens und der Geldflüsse. KYC beinhaltet in der Regel die Vorlage von Identitätsnachweisen durch den Benutzer in irgendeiner Form (z. B. Eingabe in ein Online-Webformular, indem einem Benutzer ein Ausweisdokument vors Gesicht gehalten wird in einer Videositzung usw.). Sichere Erstellung und Präsentation dezentraler Ausweise könnte grundsätzlich in mehrfacher Hinsicht eine vorteilhafte Alternative sein, nämlich durch: (1) Herstellung Der KYC-Prozess ist für Benutzer und Finanzinstitute effizienter, da einmal a Wenn der Ausweis erhalten wird, kann er problemlos jedem Finanzinstitut vorgelegt werden. (2) Reduzierung von Betrug durch Verringerung der Möglichkeiten für Identitätsdiebstahl durch Kompromittierung von personenbezogenen Daten (PII) und Spoofing während der Videoüberprüfung; und (3) Verringerung des Risikos einer PII-Kompromittierung in Finanzinstituten, da die Benutzer die Kontrolle behalten ihrer eigenen Daten. Angesichts der Strafen in Höhe von mehreren Milliarden US-Dollar, die Finanzinstitute für Verstöße gegen die AML-Compliance zahlen, und der Tatsache, dass viele Finanzinstitute jährlich Millionen von US-Dollar für KYC ausgeben, könnten Verbesserungen für Finanzinstitute zu erheblichen Einsparungen führen und im weiteren Sinne für Verbraucher [196]. Während der traditionelle Finanzsektor langsam ist Um neue Compliance-Tools einzuführen, nutzen DeFi Systeme diese zunehmend [43]. Beispielanwendung: Unterbesicherte Kredite: Die meisten DeFi Anwendungen, die Heutzutage werden bei der Förderkreditvergabe ausschließlich vollständig besicherte Kredite vergeben. Dabei handelt es sich um Kredite an Kreditnehmer, die Vermögenswerte in Kryptowährung hinterlegen, deren Wert den Kreditwert übersteigt. In letzter Zeit ist Interesse an Krediten entstanden, die in der DeFi-Community allgemein als unterbesicherte Kredite bezeichnet werden. Im Gegensatz dazu handelt es sich um Kredite, für die entsprechende Sicherheiten bestehen Der Wert ist geringer als der Kapitalbetrag des Darlehens. Unterbesicherte Kredite ähneln Krediten, die oft von traditionellen Finanzinstituten vergeben werden. Anstatt sich zu verlassen Stattdessen stützen sie sich bei der Kreditvergabe auf hinterlegte Sicherheiten als Garantie für die Kreditrückzahlung Entscheidungen über die Kredithistorie von Kreditnehmern. 7Diese Transformation basiert auf einer verteilten Pseudozufallsfunktion (PRF).Unterbesicherte Kredite stellen einen im Entstehen begriffenen, aber wachsenden Teil des DeFi Kreditmarktes dar. Sie stützen sich auf Mechanismen, wie sie auch im traditionellen Finanzwesen eingesetzt werden Institutionen, wie z. B. Rechtsverträge [91]. Eine wesentliche Voraussetzung für ihr Wachstum wird die Fähigkeit sein, Daten zur Kreditwürdigkeit von Benutzern – einem Schlüsselfaktor bei herkömmlichen Kreditentscheidungen – auf eine Weise an DeFi-Systeme zu übermitteln, die eine starke Integrität gewährleistet, d. h. Gewährleistung korrekter Daten. Ein DON-fähiges dezentrales Identitätssystem würde potenziellen Kreditnehmern dies ermöglichen Generieren Sie hochsichere Referenzen, die Ihre Kreditwürdigkeit belegen und gleichzeitig erhalten bleiben die Vertraulichkeit sensibler Informationen. Konkret können Kreditnehmer diese generieren Anmeldeinformationen basierend auf Aufzeichnungen aus maßgeblichen Online-Quellen, wobei nur die offengelegt werden Daten, die durch DON bestätigt wurden, ohne andere, potenziell sensible Daten preiszugeben. Für Beispielsweise kann ein Kreditnehmer einen Berechtigungsnachweis erstellen, der seine Kreditwürdigkeit bei einem angibt Eine Gruppe von Kreditauskunfteien überschreitet einen bestimmten Schwellenwert (z. B. 750), ohne sie preiszugeben genaue Punktzahl oder andere Daten in ihren Unterlagen. Zusätzlich, falls gewünscht, solche Anmeldeinformationen können anonym generiert werden, d. h. der Name des Benutzers kann als sensible Daten behandelt werden und selbst nicht den oracle-Knoten oder in ihren dezentralen Anmeldeinformationen ausgesetzt. Der Ausweis selbst kann je nach Anwendung in der Kette oder außerhalb der Kette verwendet werden. Zusammenfassend lässt sich sagen, dass ein Kreditnehmer den Kreditgebern wesentliche Informationen zu seiner Kreditwürdigkeit zur Verfügung stellen kann Geschichten mit starker Integrität und ohne Risiko der Offenlegung unnötiger, sensibler Informationen Daten. Ein Kreditnehmer kann auch eine Reihe anderer vertraulicher Berechtigungsnachweise vorlegen hilfreich bei Kreditentscheidungen. Beispielsweise können Ausweise die Identität eines Kreditnehmers belegen Besitz von (Off-Chain-)Vermögenswerten, wie wir in unserem nächsten Beispiel zeigen. Beispielanwendung: Akkreditierung: Viele Gerichtsbarkeiten beschränken die Anlegerklasse, an die nicht registrierte Wertpapiere verkauft werden dürfen. In den USA beispielsweise SEC Verordnung D legt fest, dass für die Akkreditierung für solche Investitionsmöglichkeiten ein Die Person muss über ein Nettovermögen von 1 Million US-Dollar verfügen, bestimmte Mindesteinkommensanforderungen erfüllen oder über bestimmte berufliche Qualifikationen verfügen [209, 210]. Aktuelle Akkreditierung Die Prozesse sind umständlich und ineffizient und erfordern oft ein Bescheinigungsschreiben von ein Buchhalter oder ein ähnlicher Nachweis. Ein dezentrales Identitätssystem würde es Benutzern ermöglichen, Anmeldeinformationen zu generieren bestehende Online-Finanzdienstleistungskonten, die die Einhaltung der Akkreditierung nachweisen Vorschriften, die einen effizienteren und datenschutzschonenden KYC-Prozess ermöglichen. Die Die datenschutzrechtlichen Eigenschaften von DECO und Town Crier würden dies darüber hinaus ermöglichen Anmeldeinformationen müssen mit hoher Integritätsgarantie generiert werden, ohne dass Details zum Finanzstatus eines Benutzers direkt preisgegeben werden. Beispielsweise könnte ein Benutzer einen Berechtigungsnachweis generieren Sie beweist, dass sie über ein Nettovermögen von mindestens 1 Million US-Dollar verfügt, ohne weitere Angaben zu machen Informationen über ihre finanzielle Situation. 4.4 Prioritätskanäle Prioritätskanäle sind ein nützlicher neuer Dienst, der mit einem DON einfach zu erstellen ist. Ihr

Ziel ist es, ausgewählte Transaktionen mit hoher Priorität zeitnah auf MAINCHAIN bereitzustellen in Zeiten der Netzwerküberlastung. Prioritätskanäle können als eine Form von angesehen werden Futures-Kontrakt auf Blockraum und damit als Kryptoware, ein als Teil geprägter Begriff des Projekts Chicago [61, 136]. Prioritätskanäle sind speziell für Miner gedacht, um Infrastrukturdienste wie oracles, Governance-Funktionen für Verträge usw. zu ermöglichen – nicht für normale Aktivitäten auf Benutzerebene wie Finanztransaktionen. Tatsächlich, wie hier entworfen, eine Priorität Der Kanal kann nur von weniger als 100 % der Mining-Leistung im Netzwerk implementiert werden bieten lockere Grenzen für die Lieferzeiten und verhindern so, dass sie für stark geschwindigkeitsabhängige Zwecke verwendet werden können Ziele wie Frontrunning. Abbildung 10: Ein Prioritätskanal ist eine Garantie eines Miners M – oder allgemeiner: a Gruppe von Minern M – einem Benutzer U, dass seine Transaktion τ innerhalb von D Blöcken abgebaut wird der Aufnahme in den Mempool. Ein Vertrags-SC kann die DON-Überwachung verwenden, um dies durchzusetzen Servicebedingungen des Kanals. Ein Prioritätskanal hat die Form einer Vereinbarung zwischen einem Miner oder einer Gruppe von Minern (oder Mining-Pools) M, der den Kanal bereitstellt, und ein Benutzer U, der eine Gebühr für den Zugriff zahlt. M stimmt zu, dass, wenn U eine Transaktion τ an den Mempool übermittelt (mit einem beliebigen Gaspreis,(aber ein vorher vereinbarter Gasgrenzwert), wird M es innerhalb der nächsten D-Blöcke in die Kette einbinden.8 Die Idee ist schematisch in Abb. 10 dargestellt. Beschreibung des Priority-Channel-Vertrags: Ein Prioritätskanal kann als realisiert werden Hybrid smart contract ungefähr wie folgt. Wir lassen SC die Logik auf MAINCHAIN bezeichnen und das am DON von exec. SC akzeptiert eine Anzahlung/einen Einsatz von \(d from M and an advance payment \)p von U. A DON Executable Exec überwacht den Mempool und wird bei der Platzierung einer Transaktion ausgelöst von U. Es sendet eine Erfolgsmeldung an SC, wenn U eine Transaktion übermittelt, in der M Mining durchführt rechtzeitig und eine Fehlermeldung im Falle eines Serviceausfalls. SC sendet bei einer Erfolgsmeldung die Zahlung $p an M und sendet alle verbleibenden Mittel, einschließlich $d, an U, wenn eine Fehlermeldung empfangen wird. Nach erfolgreicher Beendigung wird es gibt Anzahlung $d an M frei. Der Miner M kann natürlich mehrere Prioritätskanäle gleichzeitig bereitstellen Benutzer und können mit U einen Prioritätskanal für eine vorher vereinbarte Anzahl von Nachrichten öffnen. 4.5 Vertraulichkeit wahren DeFi / Mixicles Heutzutage bieten DeFi Anwendungen [1] kaum oder gar keine Vertraulichkeit für Benutzer: Alle Transaktionen sind in der Kette sichtbar. Verschiedene wissensfreie Ansätze, z. B. [149, 217], können Transaktionsdatenschutz bieten, und die TEF ist allgemein genug, um sie zu unterstützen. Aber Diese Ansätze sind nicht umfassend und verbergen beispielsweise in der Regel nicht die Vermögenswert, auf dem eine Transaktion basiert. Die breite Palette an Rechenwerkzeugen, die wir letztendlich in DONs unterstützen wollen, wird es tun Ermöglichen Sie den Datenschutz auf verschiedene Weise, um solche Lücken zu schließen und so die Datenschutzgarantien anderer Systeme zu ergänzen. Beispielsweise kann Mixicles, ein vertrauliches DeFi Instrument, das von Chainlink Labs-Forschern [135] vorgeschlagen wurde, verbergen der Vermögenswerttyp, der ein Finanzinstrument abdeckt, und passt ganz natürlich in die DON Rahmen. Mixicles lassen sich am einfachsten anhand ihrer Verwendung zur Realisierung einer einfachen Binärdatei erklären Option. Eine binäre Option ist ein Finanzinstrument, bei dem zwei Benutzer, was wir tun werden Siehe hier für Konsistenz mit [135] als Spieler, wetten Sie auf ein Ereignis mit zwei möglichen Ergebnisse, z. B. ob ein Vermögenswert zu einem vorher festgelegten Zeitpunkt einen Zielpreis überschreitet oder nicht. Das folgende Beispiel veranschaulicht die Idee. Beispiel 2. Alice und Bob sind Parteien einer binären Option, die auf dem Wert eines Vermögenswerts basiert namens Carol’s Bubble Token (CBT). Alice setzt darauf, dass CBT einen Marktpreis von at haben wird mindestens 250 USD zum Zeitpunkt T = Mittag am 21. Juni 2025; Bob setzt auf das Gegenteil. Jeder Spieler zahlt 100 ETH bis zu einer festgelegten Frist ein. Der Spieler mit der Gewinnposition erhält 200 ETH (d. h. gewinnt 100 ETH). 8D muss natürlich groß genug sein, um sicherzustellen, dass M mit hoher Wahrscheinlichkeit eingehalten werden kann. Für Wenn M beispielsweise 20 % der Mining-Leistung im Netzwerk kontrolliert, könnte es D = 100 wählen, um sicherzustellen eine Ausfallwahrscheinlichkeit von ≈2 × 10−10, also weniger als eins zu einer Milliarde.Bei einem vorhandenen Chainlink oracle Netzwerk O ist es einfach, ein Smart zu implementieren Vertrag SC, der die Vereinbarung in Beispiel 2 umsetzt. Die beiden Spieler zahlen jeweils ein 100 ETH in SC. Irgendwann nach T wird eine Anfrage q an O gesendet, in der der Preis r von abgefragt wird CBT zum Zeitpunkt T. O sendet einen Bericht über diesen Preis an SC. SC schickt dann Geld an Alice wenn r ≥250 und Bob, wenn nicht. Dieser Ansatz deckt jedoch r in der Kette auf – was es einfach macht für einen Beobachter, um den der binären Option zugrunde liegenden Vermögenswert abzuleiten. In der Terminologie von Mixicles ist es hilfreich, das Ergebnis konzeptionell zu betrachten von SC in Form eines Switches, der einen als Prädikat berechneten Binärwert überträgt Schalter(r). In unserem Beispiel ist switch(r) = 0, wenn r ≥250; Angesichts dieses Ergebnisses gewinnt Alice. Andernfalls ist switch(r) = 1 und Bob gewinnt. Ein DON kann einen Basis-Mixicle als Hybridvertrag realisieren, indem er eine ausführbare Datei ausführt exec, das switch(r) berechnet und es in der Kette an SC meldet. Wir zeigen diese Konstruktion in Abb. 11. Abbildung 11: Diagramm des Basis-Mixicle in Beispiel 2. Zur Gewährleistung der Geheimhaltung in der Kette Melden Sie r und damit den der binären Option zugrunde liegenden Vermögenswert, den Sie an den oracle senden Vertrag SC über Switch nur den Binärwert switch(r). Wir spezifizieren in Anhang C.3 einen Adapter ConfSwitch, der dies einfach macht Tor in einem DON. Die Grundidee hinter ConfSwitch ist recht einfach. Statt zu berichten Der Wert r, ConfSwitch meldet nur den binären Schalterwert switch(r). SC kann sein Entwickelt, um eine korrekte Zahlung allein auf der Grundlage von switch(r) und switch(r) selbst durchzuführen gibt keine Informationen über den zugrunde liegenden Vermögenswert preis – in unserem Beispiel CBT. Darüber hinaus durch Platzieren eines Chiffretexts auf (q, r) im Hauptbuch, verschlüsselt unter pkaud, dem öffentlichen Schlüssel von Als Prüfer erstellt der Adapter ConfSwitch einen vertraulichen Prüfpfad. Der grundlegende Mixicle, den wir der Einfachheit halber ausgewählt haben, um ihn hier zu beschreiben, verbirgt nur die Vermögenswert und Einsatz hinter der binären Option in unserem Beispiel. Eine vollwertige Mixicle [135]-Dose bieten zwei Formen der Vertraulichkeit. Es verbirgt vor Beobachtern: (1) Welches Ereignis das Spieler wetten auf (d. h. q und r), aber auch (2) Welcher Spieler hat die Wette gewonnen? Da Mixicles auf MAINCHAIN ausgeführt werden, müsste ein Spieler weiterleiten switch(r) von DON zu MAINCHAIN, oder es könnte eine ausführbare Exec erstellt werden

wird bei der Ausgabe durch ConfSwitch ausgelöst und ruft einen anderen Adapter auf, an den switch(r) gesendet werden soll HAUPTKETTE. Eine dritte, subtile Art der Vertraulichkeit ist ebenfalls eine Überlegung wert. In einer Basisimplementierung von ConfSwitch führt O den Adapter auf dem DON aus und lernt so das Vermögenswert – in unserem Beispiel CBT – und damit die Natur der binären Option. Wie besprochen In Anhang C.3 ist es jedoch zusätzlich möglich, DECO oder Town Crier zu verwenden verschweige auch diese Informationen vor O. In diesem Fall erfährt der O keine weiteren Informationen als ein öffentlicher Beobachter von SC. Für weitere Einzelheiten zu Mixicles verweisen wir die Leser auf [135].

Faire Sequenzierungsdienste

Ein wichtiger Dienst, den wir voraussichtlich von DONs anbieten werden und der ihre Netzwerk-, Rechen- und Speicherkapazitäten nutzt, heißt Fair Sequencing Services (FSS). Obwohl FSS einfach als eine im DON-Framework realisierte Anwendung betrachtet werden kann, heben wir es als einen Dienst hervor, von dem wir glauben, dass er überall stark nachgefragt werden wird blockchains, und wir erwarten, dass das Netzwerk Chainlink aktiv unterstützt. Bei der Ausführung in öffentlichen blockchain-Netzwerken sind viele der heutigen DeFi-Anwendungen offenbaren Informationen, die von Benutzern zu ihrem eigenen Vorteil ausgenutzt werden können, analog zu die Art von Insider-Lecks und Manipulationsmöglichkeiten, die in der Realität allgegenwärtig sind Märkte [64, 155]. Stattdessen ebnet FSS den Weg zu einem fairen DeFi Ökosystem. FSS hilft Entwicklern, DeFi Verträge zu erstellen, die vor Marktmanipulation geschützt sind die auf Informationslecks zurückzuführen sind. Angesichts der Probleme, die wir unten hervorheben, ist FSS dies Besonders attraktiv für Layer-2-Dienste und passt in den Rahmen für solche Dienste die wir in Abschnitt 6 besprechen. Die Herausforderung: In bestehenden erlaubnislosen Systemen sind Transaktionen vollständig geordnet im Ermessen der Bergleute. In Netzwerken mit Berechtigungen können die validator-Knoten Druck ausüben die gleiche Kraft. Dies ist eine Form der weitgehend unerkannten kurzlebigen Zentralisierung in ansonsten dezentrale Systeme. Ein Miner kann dafür Transaktionen (vorübergehend) zensieren eigenen Nutzen [171] oder sie neu anordnen, um den eigenen Gewinn zu maximieren, ein Begriff namens MinerExtractable Value (MEV) [90]. Der Begriff MEV ist etwas irreführend: Er bezieht sich nicht Nur um den Wert zu erhöhen, den Bergleute erfassen können: Einige MEV können von normalen Benutzern erfasst werden. Da Miner jedoch mehr Macht haben als normale Benutzer, stellt MEV eine Obergrenze für den Wert dar, den ein Unternehmen durch gegnerische Neuordnung erzielen kann und ergänzende Transaktionseinfügung. Selbst wenn Bergleute Transaktionen einfach anordnen basierend auf Gebühren (Gas), ohne Manipulation können Benutzer selbst die Gaspreise manipulieren um ihre Transaktionen gegenüber weniger anspruchsvollen Transaktionen zu bevorzugen. Daian et al. [90] dokumentieren und quantifizieren die Vorgehensweise von Bots (nicht Minern). Nutzen Sie die Gasdynamik in einer Weise, die Benutzern von DeFi-Systemen heute schadet, und wie MEV bedroht sogar die Stabilität der zugrunde liegenden Konsensschicht in einem blockchain. Weitere Beispiele für die Manipulation von Transaktionsreihenfolgen tauchen regelmäßig auf, z. B. [50, 154].Neue Methoden zur Transaktionsverarbeitung wie rollups sind ein vielversprechender Ansatz zu den Skalierungsproblemen von blockchains mit hohem Durchsatz. Sie gehen jedoch nicht darauf ein das Problem des MEV. Stattdessen übertragen sie es auf die Entität, die rollup generiert. Das Entität, sei es der Betreiber eines smart contract oder ein Nutzer, der einen (zk-)rollup mit einrichtet ein Gültigkeitsnachweis, hat die Befugnis, Transaktionen anzuordnen und einzugeben. Mit anderen Worten: rollups tauschen Sie MEV gegen REV: Rollup-extrahierbarer Wert. MEV wirkt sich auf bevorstehende Transaktionen aus, die an den Mempool übermittelt wurden sind aber noch nicht in der Kette festgeschrieben. Informationen zu solchen Transaktionen sind breit gefächert im Netzwerk verfügbar. Miner, validators und normale Netzwerkteilnehmer können Nutzen Sie daher dieses Wissen und erstellen Sie abhängige Transaktionen. Darüber hinaus können Miner und validators die Reihenfolge der von ihnen durchgeführten Transaktionen beeinflussen sich selbst und nutzen dies zu ihrem Vorteil. Das Problem des unangemessenen Einflusses von Führungskräften auf die Reihenfolge der Transaktionen im Konsens Protokolle sind in der Literatur seit den 1990er Jahren bekannt [71, 190], jedoch nicht zufriedenstellend Lösungen wurden bisher in der Praxis realisiert [97]. Der Hauptgrund liegt darin, dass vorgeschlagene Lösungen – zumindest bis vor kurzem – nicht ohne weiteres in die Öffentlichkeit integriert werden können blockchains, da sie darauf vertrauen, dass der Inhalt der Transaktionen bis dahin geheim bleibt Ihre Reihenfolge wurde festgelegt. Übersicht über Fair Sequencing Services (FSS): DONs stellt Tools zur Dezentralisierung der Transaktionsreihenfolge bereit und implementiert sie gemäß einer von einem Vertrauensgeber festgelegten Richtlinie Vertragsersteller, idealerweise einer, der fair ist und die Akteure, die dies wünschen, nicht begünstigt Manipulation der Transaktionsreihenfolge. Zusammen bilden diese Tools FSS. FSS umfasst drei Komponenten. Das erste ist die Überwachung von Transaktionen. Im FSS, oracle Knoten in O überwachen beide den Mempool von MAINCHAIN und erlauben (falls gewünscht). Off-Chain-Übermittlung von Transaktionen über einen speziellen Kanal. Die zweite Möglichkeit ist die Reihenfolge der Transaktionen. Die Knoten in O-Reihenfolgetransaktionen für einen vertrauenden Vertrag gemäß einer für diesen Vertrag festgelegten Richtlinie. Der dritte Schritt ist die Buchung von Transaktionen. Nachdem die Transaktionen bestellt wurden, senden die Knoten in O gemeinsam die Transaktionen an die Hauptkette. Zu den potenziellen Vorteilen von FSS gehören: • Auftragsgerechtigkeit: FSS umfasst Tools, die Entwicklern dabei helfen, sicherzustellen, dass Transaktionen durchgeführt werden Die Eingaben in einen bestimmten Vertrag werden so angeordnet, dass sie nicht unfair sind Vorteil für gut ausgestattete und/oder technisch versierte Benutzer. Bestellrichtlinien können hierfür angegeben werden. • Reduzierung oder Beseitigung von Informationslecks: Indem sichergestellt wird, dass Netzwerkteilnehmer kein Wissen über bevorstehende Transaktionen ausnutzen können, kann FSS diese verringern oder Eliminieren Sie Angriffe wie Front-Running, die auf verfügbaren Informationen basieren das Netzwerk, bevor Transaktionen festgeschrieben werden. Verhinderung der Ausbeutung solcher Durch Lecks wird sichergestellt, dass kontroverse Transaktionen, die vom Original abhängen, ausstehen Transaktionen können nicht in das Hauptbuch eingehen, bevor die ursprünglichen Transaktionen festgeschrieben wurden.• Reduzierte Transaktionskosten: Da Spieler nicht mehr auf Geschwindigkeit bei der Übermittlung angewiesen sind Wenn Sie ihre Transaktionen an einen smart contract senden, kann FSS die Kosten für die Transaktionsverarbeitung erheblich senken. • Prioritätsreihenfolge: FSS kann kritischen Transaktionen automatisch eine besondere Priorität zuweisen bestellen. Um beispielsweise Front-Running-Angriffe gegen oracle zu verhindern B. [79], kann FSS einen oracle-Bericht in einen Transaktionsstrom einfügen rückwirkend. Ein übergeordnetes Ziel des FSS in DONs besteht darin, DeFi-Erstellern die Möglichkeit zu geben, fair zu arbeiten Finanzsysteme, also Systeme, die keinen bestimmten Benutzern (oder Minern) Vorteile bringen gegenüber anderen aufgrund von Geschwindigkeit, Insiderwissen oder technischer Leistungsfähigkeit Manipulation. Während eine klare, allgemeine Vorstellung von Fairness schwer zu fassen ist und vollkommene Fairness in Jeder vernünftige Sinn ist unerreichbar. FSS möchte Entwicklern eine leistungsstarke Lösung bieten Eine Reihe von Tools, mit denen sie Richtlinien durchsetzen können, die dabei helfen, ihre Designziele für DeFi zu erreichen. Wir stellen fest, dass das Hauptziel von FSS darin besteht, als fairer Sequenzierungsdienst für zu fungieren die MAINCHAIN, auf die DONs abzielt, einige der gleichen Fairness-Desiderate wie FSS Garantien können auch für (dezentrale) Protokolle sinnvoll sein, die untereinander ausgeführt werden DON Partys. Somit kann FSS allgemeiner als ein Dienst betrachtet werden, der von einer Teilmenge bereitgestellt wird von DON Knoten, um nicht nur die von Benutzern von MAINCHAIN gesendeten Transaktionen fair zu sequenzieren aber auch Transaktionen (d. h. Nachrichten), die von anderen DON-Knoten gemeinsam genutzt werden. In diesem Abschnitt Wir werden uns hauptsächlich auf das Ziel der Sequenzierung von MAINCHAIN-Transaktionen konzentrieren. Abschnittsorganisation: In Abschnitt 5.1 beschreiben wir zwei übergeordnete Anwendungen, die das Design von FSS motivieren: Verhindern des Frontrunnings von oracle-Berichten und Verhindern Front-Running von Benutzertransaktionen. Anschließend stellen wir weitere Details zum Design von FSS bereit in Abschnitt 5.2. Abschnitt 5.3 beschreibt Beispiele für faire Bestellgarantien und -mittel um sie zu erreichen. Abschließend werden in Abschnitt 5.4 und Abschnitt 5.5 Bedrohungen auf Netzwerkebene erörtert solche Richtlinien und Mittel, um sie anzugehen, jeweils für Netzwerküberschwemmungen und Sybil Angriffe. 5.1 Das Front-Running-Problem Um die Ziele und das Design von FSS zu erklären, beschreiben wir zwei allgemeine Formen des Front-Runnings Angriffe und die Grenzen bestehender Lösungen. Front-Running ist ein Beispiel für eine Klasse von Transaction-Ordering-Angriffen: Es gibt eine Reihe verwandter Angriffe wie Backrunning und Sandwiching (Front-Running plus Back-Running) [237], die wir nicht behandeln hier, aber FSS hilft auch bei der Lösung. 5.1.1 Oracle Front-Running In ihrer traditionellen Rolle der Bereitstellung von Off-Chain-Daten für blockchain-Anwendungen, oracles ein natürliches Ziel für Frontangriffe werden.Betrachten Sie das gängige Entwurfsmuster, bei dem ein oracle zur Bereitstellung verschiedener Preis-Feeds verwendet wird an eine On-Chain-Börse: In regelmäßigen Abständen (z. B. jede Stunde) sammelt der oracle Preisdaten für verschiedene Vermögenswerte und sendet diese an einen Tauschvertrag. Diese Preis-Daten-Transaktionen bieten offensichtliche Arbitragemöglichkeiten: Zum Beispiel, wenn der neueste oracle-Bericht aufgeführt ist ein viel höherer Preis für einen Vermögenswert, an den ein Gegner den oracle-Bericht richten könnte Vermögenswerte aufkaufen und sofort weiterverkaufen, sobald der Bericht des oracle bearbeitet wurde. Geschwindigkeitsbegrenzungen und rückwirkende Preisgestaltung: Eine natürliche Lösung für das oracle-Frontrunning-Problem besteht darin, oracle-Berichten besondere Priorität gegenüber anderen Transaktionen einzuräumen. Für Beispielsweise könnten oracle-Berichte mit hohen Gebühren versendet werden, um Bergleute zur Verarbeitung zu ermutigen sie zuerst. Dies wird jedoch nicht verhindern, dass man an vorderster Front auftritt, wenn die Arbitragemöglichkeit hoch ist. Es kann auch keine Arbitrage durch die Bergleute selbst verhindern. Einige Börsen sind daher dazu übergegangen, schwerwiegendere „Speedbumps“ zu implementieren, wie etwa das Einreihen von Benutzertransaktionen für eine Reihe von Blöcken vor der Verarbeitung oder die Preise rückwirkend anpassen, wenn ein neuer oracle-Bericht eintrifft. Die Nachteile dieser Lösungen bestehen darin, dass sie die Implementierung des Austauschs komplexer machen. erhöhen den Speicherbedarf und damit die Transaktionskosten und beeinträchtigen das Benutzererlebnis, da der Austausch von Vermögenswerten erst nach einer erheblichen Zeitspanne bestätigt wird. Huckepack: Bevor wir zu FSS übergehen, besprechen wir Huckepack, ein ganz einfaches und einfaches Verfahren elegante Lösung für das Front-Running-Problem oracle. Es gilt nicht für die Adresse In anderen Szenarien ist sie jedoch führend. Kurz gesagt, anstatt regelmäßig Berichte an den On-Chain-Vertrag zu senden, oracles Veröffentlichen Sie signierte Berichte, die Benutzer beim Kauf oder Verkauf an ihre Transaktionen anhängen On-Chain-Assets. Die Börse prüft dann lediglich, ob der Bericht gültig und aktuell ist (z. B. oracle kann einen Bereich von Blöcken signieren, für den der Bericht gültig ist) und extrahiert daraus den entsprechenden Preis-Feed. Dieser einfache Ansatz hat gegenüber der oben genannten „Geschwindigkeitsschwelle“ eine Reihe von Vorteilen. Ansatz: (1) Der Börsenvertrag muss den Stand der Preis-Feeds nicht beibehalten, was auch der Fall sein sollte zu geringeren Transaktionskosten führen; (2) Da oracle-Berichte nach Bedarf in der Kette veröffentlicht werden, können oracles dadurch häufigere Aktualisierungen generieren (z. B. jede Minute). Minimierung von Arbitragemöglichkeiten durch die Erstellung eines Berichts9; (3) Transaktionen können sofort validiert werden, da sie immer einen aktuellen Preis-Feed enthalten. Der Ansatz ist jedoch nicht perfekt. Erstens bringt diese Huckepack-Lösung die Es liegt in der Verantwortung der Benutzer der Börse, aktuelle oracle-Berichte abzurufen und sie an ihre Börsen anzuhängen Transaktionen. Zweitens minimiert das Huckepack-Prinzip zwar die Arbitragemöglichkeiten, kann es aber nicht Verhindern Sie sie vollständig, ohne die Gültigkeit des On-Chain-Vertrags zu beeinträchtigen. In der Tat, wenn ein Der oracle-Bericht ist bis zu einer Blocknummer n gültig und sendet dann eine Transaktion an den Block n + 1 würde einen neuen gültigen Bericht erfordern. Aufgrund inhärenter Verzögerungen bei der Ausbreitung von Berichte von oracles an Benutzer, der neue Bericht, der für Block n + 1 gültig wäre 9Arbitrage lohnt sich nur dann, wenn die ausnutzbare Differenz der Vermögenspreise die irrelevante übersteigt Gebühren, die für den Kauf und Verkauf der Vermögenswerte erforderlich sind, z. B. die von Bergleuten und der Börse erhobenen Gebühren.einige Zeit bevor Block n + 1 abgebaut wird, beispielsweise bei Block n − k, veröffentlicht werden Erstellen einer Folge von k Blöcken, in denen eine kurzlebige Arbitragemöglichkeit besteht. Wir Beschreiben Sie nun, wie FSS diese Einschränkungen umgeht. Priorisieren von oracle-Berichten mit FSS: FSS kann das oracle-Frontrunning angehen Problem, indem man auf der oben genannten Huckepack-Lösung aufbaut, aber die zusätzliche Lösung vorantreibt Arbeit zur Erweiterung von Transaktionen mit oracle-Berichten an das dezentrale Oracle-Netzwerk. Auf hoher Ebene sammeln oracle-Knoten Transaktionen, die für einen On-Chain-Austausch bestimmt sind. Vereinbaren Sie einen Preis-Feed in Echtzeit und veröffentlichen Sie den Preis-Feed zusammen mit den gesammelten Transaktionen im Hauptkettenvertrag. Konzeptionell kann man sich diesen Ansatz als einen vorstellen „Data-Augmented Transaction Batching“, bei dem oracle für eine Aktualität sorgt Der Preis-Feed wird immer zu Transaktionen hinzugefügt. FSS-Lösungen können für die Benutzer der Börse transparent implementiert werden minimale Änderungen an der Vertragslogik, wie wir in Abschnitt 5.2 ausführlicher beschreiben. Sicherstellen Dass neue oracle-Berichte immer Vorrang vor Benutzertransaktionen haben, ist nur ein Beispiel einer Bestellpolitik, die FSS übernehmen und durchsetzen kann. Richtlinien der FSS zur Gewährleistung der Ordnung Fairness werden allgemeiner in Abschnitt 5.3 beschrieben. 5.1.2 Front-Running-Benutzertransaktionen Wir wenden uns nun dem Front-Running in generischen Anwendungen zu, wo die oben beschriebene Verteidigungsmethode angewendet wird funktioniert nicht. Das Problem kann grob durch das folgende Szenario erfasst werden: Ein Angreifer sieht, wie eine Benutzertransaktion tx1 in das P2P-Netzwerk gesendet wird, und fügt sie ein seine eigene gegnerische Transaktion tx2, sodass tx2 vor tx1 verarbeitet wird (z. B. durch Bezahlen). eine höhere Transaktionsgebühr). Diese Art des Front-Runnings ist beispielsweise weit verbreitet Bots, die Arbitragemöglichkeiten in DeFi Systemen [90] ausnutzen und Benutzer von betroffen haben verschiedene dezentrale Anwendungen [101]. Durchsetzung einer fairen Ordnung zwischen den Transaktionen Die auf blockchain verarbeitete Datei behebt dieses Problem. Grundsätzlich ist es manchmal nicht einmal notwendig, die Details von tx1 zu sehen Das Wissen um seine bloße Existenz kann es einem Gegner ermöglichen, tx1 durch ihn hindurch in den Vordergrund zu drängen Besitzen Sie tx2 und betrügen Sie den unschuldigen Benutzer, der tx1 erstellt hat. Beispielsweise könnte der Benutzer bekannt dafür, regelmäßig mit einem bestimmten Vermögenswert zu handeln. Die Verhinderung solcher Angriffe erfordert Abhilfemaßnahmen, die auch den Verlust von Metadaten verhindern [62]. Einige Lösungen für dieses Problem existieren, aber sie führen zu Verzögerungen und Bedenken hinsichtlich der Benutzerfreundlichkeit. Von der Netzwerkordnung zur endgültigen Ordnung mit FSS: Möglichkeiten zum Frontrunning entstehen, weil bestehende Systeme über keine Mechanismen verfügen, um sicherzustellen, dass die Reihenfolge eingehalten wird Transaktionen, die in der Kette erscheinen, respektieren die Reihenfolge der Ereignisse und den Informationsfluss außerhalb des Netzwerks. Hierbei handelt es sich um ein Problem, das auf Mängel bei der Implementierung von Anwendungen (z. B. Handelsplattformen) auf einem blockchain zurückzuführen ist. Im Idealfall würde man das tun Stellen Sie sicher, dass Transaktionen auf blockchain in derselben Reihenfolge festgeschrieben werden, in der sie waren erstellt und an das P2P-Netzwerk von blockchain gesendet. Aber seit dem blockchain Netzwerk

verteilt wird, kann keine solche Bestellung erfasst werden. FSS führt daher Mechanismen ein zur Absicherung gegen Lauterkeitsverstöße, die allein aufgrund der Verteilung entstehen Art des blockchain-Netzwerks. 5.2 FSS-Details Abbildung 12: Orderfairer Mempool mit zwei verschiedenen Transaktionspfaden: direkt und Mempool-basiert. Abb. 12 zeigt ein allgemeines Schema des FSS. Um Fairness zu gewährleisten, muss der DON bereitstellende FSS in den Fluss der Transaktionen eingreifen, wenn diese in die MAINCHAIN ​​gelangen. Möglicherweise sind Anpassungen an Clients, an smart contracts auf MAINCHAIN ​​oder an beiden erforderlich. Auf einer hohen Ebene kann die Verarbeitung von Transaktionen durch FSS in drei Bereiche unterteilt werden Phasen, die im Folgenden beschrieben werden: (1) Transaktionsüberwachung; (2) Transaktionssequenzierung; und (3) Transaktionsbuchung. Abhängig von der für die Transaktionssequenzierung verwendeten Bestellmethode sind zusätzliche Protokollschritte erforderlich, wie im nächsten Abschnitt beschrieben. 5.2.1 Transaktionsverarbeitung Transaktionsüberwachung: Wir stellen uns zwei unterschiedliche Ansätze für die Überwachung durch FSS vor Benutzertransaktionen, die für einen bestimmten smart contract bestimmt sind, direkt und mempoolbasiert: • Direkt: Der direkte Ansatz ist konzeptionell am einfachsten, erfordert jedoch Änderungen Benutzer-Clients, sodass Transaktionen direkt an das dezentrale Oracle gesendet werdenNetzwerkknoten und nicht die Knoten der Hauptkette. Der DON sammelt Benutzertransaktionen, die für einen bestimmten smart contract SC bestimmt sind, und ordnet sie basierend darauf auf einige Bestellrichtlinien. Der DON sendet dann die bestellten Transaktionen an den smart contract in der Hauptkette. Einige Bestellmechanismen erfordern auch den direkten Ansatz, da der Benutzer, der eine Transaktion erstellt, kryptografisch vorgehen muss Schützen Sie es, bevor Sie es an FSS senden. • Mempool-basiert: Um die Integration von FSS mit Legacy-Clients zu erleichtern, ist der DON kann Mempool Services (MS) verwenden, um den Mempool der Hauptkette zu überwachen und zu sammeln Transaktionen. Für viele Verträge dürfte die direkte Übermittlung die bevorzugte Umsetzung sein, und wir glauben, dass es in vielen Fällen ziemlich praktisch sein sollte. Wir diskutieren kurz, wie vorhandene DApps zur Unterstützung minimal geändert werden könnten direkte Übertragung unter Beibehaltung einer guten Benutzererfahrung. Wir beschreiben Ansätze Verwenden von Ethereum und MetaMask [6], da dies heute die beliebtesten Optionen sind, aber Die genannten Techniken sollten sich auf andere Ketten und Wallets erstrecken. Ein aktueller Ethereum Verbesserungsvorschlag, „EIP-3085: Wallet add Ethereum Chain RPC method“ [100], erleichtert die Ausrichtung auf benutzerdefinierte Ethereum-Ketten (unter Verwendung einer anderen CHAIN-ID als das von MAINCHAIN, um Replay-Angriffe zu verhindern) von MetaMask und anderen browserbasierten Wallets. Nach der Umsetzung dieses Vorschlags möchte eine DApp ein DON verwenden würde ihrem Frontend einfach einen einzelnen Methodenaufruf hinzufügen, um direkt übertragen zu können Transaktionen zu jedem DON, der eine Ethereum-kompatible API verfügbar macht. In der Zwischenzeit, „EIP-712: Ethereum typisierte strukturierte Daten hashing und signieren“ [49] liefert ein wenig eine aufwändigere, aber bereits weit verbreitete Alternative, die ein DApp-Benutzer nutzen kann MetaMask zum Signieren strukturierter Daten, die eine DON-Transaktion angeben. Die DApp kann senden Diese signierten strukturierten Daten werden an DON gesendet. Abschließend stellen wir fest, dass auch hybride Ansätze möglich sind. Zum Beispiel Vermächtnis Kunden können weiterhin Transaktionen in den Mempool der Hauptkette senden, dies ist jedoch kritisch Transaktionen (z. B. oracle-Berichte) werden direkt an DON-Knoten gesendet (insbesondere die Satz von Knoten, die oracle-Berichte wie Preis-Feed-Updates bereitstellen, und der Satz von Knoten vorausgesetzt, FSS kann sich überschneiden oder identisch sein). Transaktionssequenzierung: Der Hauptzweck von FSS besteht darin, sicherzustellen, dass Benutzertransaktionen gemäß einer vordefinierten Richtlinie angeordnet werden. Die Art dieser Politik wird hängen von den Anforderungen der Anwendung und den Arten der unfairen Transaktionsanordnungen ab, die sie anordnet zielt darauf ab, zu verhindern. Da FSS auf dem DON in der Lage ist, Daten zu verarbeiten und den lokalen Status aufrechtzuerhalten, Sie können eine willkürliche Sequenzierungsrichtlinie auf der Grundlage der vorliegenden Informationen auferlegen erhältlich unter oracles. Die jeweiligen Bestellrichtlinien und ihre Umsetzung werden anschließend in Abschnitt 5.3 erläutert.Transaktionsbuchung: Nach dem Sammeln und Bestellen von Benutzertransaktionen, die entweder direkt von Benutzern empfangen oder aus dem Mempool gesammelt wurden, sendet DON diese Transaktionen an die Hauptkette. Daher bleiben die Interaktionen eines DON mit der Hauptkette bestehen unterliegt einer (potenziell unfairen) Transaktionsordnung, die von den Minern der Hauptkette geregelt wird. Um die Vorteile der dezentralen Transaktionsbestellung zu nutzen, ist das Ziel smart Der Vertrag SC muss daher so gestaltet sein, dass er den DON als Bürger „erster Klasse“ behandelt. Wir unterscheiden zwei Ansätze: • DON-only-Verträge: Die einfachste Designoption besteht darin, die Hauptkette intelligent zu gestalten Vertrags-SC akzeptiert nur Transaktionen, die vom DON verarbeitet wurden. Dies stellt sicher, dass smart contract Transaktionen in der von vorgeschlagenen Reihenfolge verarbeitet die DON, aber de facto beschränkt die smart contract auf die Arbeit in einem ausschussbasierten System (d. h. der DON-Ausschuss hat nun die fortlaufende Befugnis, die zu bestimmen Bestellung und Einbeziehung von Transaktionen). • Dual-Class-Verträge: Ein bevorzugtes, detaillierteres Design macht die Hauptkette intelligent Der Vertrags-SC akzeptiert Transaktionen, die sowohl aus dem DON als auch aus dem Legacy stammen Benutzer10, setzt jedoch traditionelle „Geschwindigkeitsschwellen“ für Transaktionen, die nicht vom DON verarbeitet wurden. Beispielsweise können Transaktionen aus dem DON verarbeitet werden sofort, während Legacy-Transaktionen durch den smart contract für „gepuffert“ werden einen festen Zeitraum. Weitere Standardmechanismen zur Verhinderung des Vorwärtslaufens wie Commit-Reveal-Schemata oder VDFs [53] könnten auch auf Legacy angewendet werden Transaktionen. Dadurch wird sichergestellt, dass DON-geordnete Transaktionen verarbeitet werden die vereinbarte Anordnung, ohne dem DON die unerwünschte Macht zur Zensur zu geben Transaktionen. Da die Einführung der Transaktionsreihenfolge durch FSS erfordert, dass Transaktionen „off-chain“ aggregiert werden, wird diese Lösung natürlich mit anderen Aggregationstechniken kombiniert, die darauf abzielen, die Verarbeitungskosten in der Kette zu senken. Zum Beispiel nach dem Sammeln und Bei der Bestellung von Transaktionen kann der DON diese Transaktionen als a an die Hauptkette senden einzelne „Batch-Transaktion“ (z. B. eine rollup), wodurch die Gesamttransaktion reduziert wird Gebühr. Durchsetzung der Transaktionsreihenfolge: Ob im DON-only- oder Dual-Class-Design, Die Hauptkette smart contract SC und der DON müssen gemeinsam gestaltet werden, um sicherzustellen, dass die Transaktionsreihenfolge des DON eingehalten wird. Auch hier stellen wir uns etwas anderes vor Gestaltungsmöglichkeiten: • Sequenznummern: Der DON kann an jede Transaktion eine Sequenznummer anhängen und diese Transaktionen an den Mempool der Hauptkette senden. Das Wichtigste 10Wenn die Transaktionsüberwachung des DON auf dem Mempool basiert, müssen Legacy-Transaktionen von DON-Transaktionen unterscheidbar sein, damit sie nicht vom DON erfasst werden, z. B. über ein spezielles Tag eingebettet in die Transaktion oder durch Angabe eines bestimmten Gaspreises, z.B. DON Transaktionen haben Gas Preise unterhalb einer bestimmten Schwelle.Kette smart contract SC ignoriert Transaktionen, die „außerhalb der Reihenfolge“ eintreffen. Wir Beachten Sie, dass die Miner der Hauptkette in dieser Einstellung entscheiden können, die DONs zu ignorieren die Transaktionsreihenfolge, was dazu führt, dass Transaktionen fehlschlagen. Durch die Beibehaltung des (teuren) Status ist es für SC möglich, die korrekte Transaktionsreihenfolge einigermaßen durchzusetzen Analog dazu, wie TCP Pakete außerhalb der Reihenfolge puffert, bis Pakete fehlen erhalten. • Transaktion nonces: Für viele blockchains und insbesondere für Ethereum gilt die Der obige Ansatz zur Sequenznummerierung kann integrierte Transaktions-nonces nutzen erzwingen, dass der Hauptketten-SC smart contract Transaktionen nacheinander verarbeitet. Hier senden die DON-Knoten Transaktionen über ein einziges Mainchain-Konto an die Hauptkette, geschützt durch einen Schlüssel, der von den DON-Knoten gemeinsam genutzt wird. Das Konto Die Transaktion nonce stellt sicher, dass Transaktionen in der richtigen Reihenfolge abgebaut und verarbeitet werden. • Transaktionen aggregieren: Der DON kann mehrere Transaktionen in einem rollup aggregieren. (oder in einem Bundle ähnlich einem rollup). Die Hauptkette smart contract muss sein Entwickelt, um solche Gesamttransaktionen abzuwickeln. • Transaktionen mit einem Hauptketten-Proxy aggregieren: Hier bündelt DON Transaktionen auf ähnliche Weise in einer „Meta-Transaktion“ für die Hauptkette, verlässt sich jedoch auf a benutzerdefinierter Proxy smart contract, um die Transaktionen zu entpacken und an den weiterzuleiten Zielvertrag SC. Diese Technik kann für die Legacy-Kompatibilität nützlich sein. Metatransaktionen verhalten sich wie rollups, unterscheiden sich jedoch darin, dass sie aus einer unkomprimierten Datei bestehen Liste der Transaktionen, die einmal in der Hauptkette gebucht wurden. Das letzte Design hat den Vorteil, dass Benutzertransaktionen nahtlos unterstützt werden werden selbst durch einen Hauptkettenvertrag vertreten, bevor sie das Ziel von DON erreichen Vertrag SC. Stellen Sie sich zum Beispiel einen Benutzer vor, der eine Transaktion an eine Wallet sendet Vertrag, der wiederum eine interne Transaktion an SC sendet. Zuweisung einer Reihenfolge Die Angabe einer Nummer für eine solche Transaktion wäre schwierig, es sei denn, der Wallet-Vertrag des Benutzers ist es Speziell entwickelt, um die Sequenznummer bei jeder internen Transaktion an weiterzuleiten SC. Ebenso können solche internen Transaktionen nicht einfach zu einer Metatransaktion zusammengefasst werden, die direkt an SC gesendet wird. Wir diskutieren weitere Designüberlegungen für Solche Proxy-Transaktionen finden Sie weiter unten. 5.2.2 Transaktionsatomarität Unsere bisherige Diskussion ist implizit davon ausgegangen, dass Transaktionen mit einem einzigen interagieren on-chain smart contract (z. B. ein Benutzer sendet eine Kaufanfrage an eine Börse). Doch, in Bei Systemen wie Ethereum kann eine einzelne Transaktion aus mehreren internen Transaktionen bestehen, z. B. wenn eine smart contract eine Funktion in einem anderen Vertrag aufruft. Unten, wir Beschreiben Sie zwei übergeordnete Strategien zur Sequenzierung von Transaktionen mit mehreren Verträgen Beibehaltung der Atomizität der Transaktion (d. h. der Abfolge von Aktionen, die durch vorgeschrieben sind). (die Transaktionen werden alle in der richtigen Reihenfolge oder gar nicht ausgeführt).Starke Atomizität: Die einfachste Lösung besteht darin, FSS wie oben beschrieben direkt auf gesamte „Multi-Contract“-Transaktionen anzuwenden. Das heißt, Benutzer senden ihre Transaktionen in das Netzwerk und FSS überwacht, sequenziert und sendet diese Transaktionen an das Netzwerk Hauptkette. Dieser Ansatz ist technisch einfach, weist jedoch eine potenzielle Einschränkung auf: Wenn ein Benutzer Die Transaktion interagiert mit zwei Verträgen SC1 und SC2, die beide fair nutzen möchten Sequenzierungsdienste, dann muss die Sequenzierungspolitik dieser beiden Verträge konsistent sein. Das heißt, es sind zwei unterschiedliche Transaktionen tx1 und tx2 gegeben, mit denen jede interagiert Sowohl SC1 als auch SC2 dürfen nicht so sein, dass die Richtlinie von SC1 tx1 vor tx2 anordnet wohingegen die Richtlinie von SC2 die umgekehrte Reihenfolge vorschreibt. Für die überwiegende Mehrheit der interessierenden Szenarien gehen wir davon aus, dass die von den verschiedenen Verträgen übernommenen Sequenzierungsrichtlinien konsistent sein werden. Zum Beispiel sowohl SC1 als auch SC2 Möglicherweise möchten Sie, dass Transaktionen nach ihrer ungefähren Ankunftszeit im Mempool sortiert werden. und SC1 möchte möglicherweise außerdem, dass bestimmte oracle-Berichte immer zuerst geliefert werden. Als die Letzterer oracle-Bericht, dass Transaktionen nicht mit SC2 interagieren, die Richtlinien sind konsistent. Schwache Atomizität: In seiner vollen Allgemeingültigkeit könnte FSS auf der Ebene des Einzelnen angewendet werden interne Transaktionen. Betrachten Sie Transaktionen der Form tx = { ˜txpre, ˜txSC, ˜txpost}, bestehend aus einigen Initialen Transaktion(en) ˜txpre, was zu einer internen Transaktion ˜txSC an SC führt, die wiederum gibt interne Transaktion(en) ˜txpost aus. Die Sequenzierungsrichtlinie von SC könnte bestimmen, wie Die interne Transaktion ˜txSC muss in Bezug auf andere gesendete Transaktionen angeordnet werden zu SC, aber lassen Sie die Reihenfolge für ˜txpre und ˜txpost offen. Angesichts der Besonderheiten der Transaktionsverarbeitung in Systemen wie Ethereum ist die Entwicklung eines Sequenzierungsdienstes, der auf bestimmte interne Transaktionen abzielt, nicht einfach. Mit einem speziell gestalteten Vertrags-SC kann dies wie folgt realisierbar sein: 1. Der Transaktionsversand wird in das Netzwerk gesendet und abgebaut (ohne jegliche Sequenzierung). durchgeführt von FSS). Der anfängliche ˜txpre wird ausgeführt und ruft ˜txSC auf. 2. SC führt ˜txSC nicht aus und kehrt zurück. 3. FSS überwacht interne Transaktionen an SC, sequenziert sie und sendet sie zurück an SC (d. h. durch Senden von Transaktionen ˜txSC direkt an SC). 4. SC verarbeitet die von FSS empfangenen Transaktionen ˜txSC und gibt interne Transaktionen ˜txpost aus, die aus ˜txSC resultieren. Bei diesem Ansatz werden Transaktionen nicht vollständig atomar (d. h. im Original) ausgeführt Transaktionsübertragung wird in mehrere On-Chain-Transaktionen aufgeteilt), aber die Reihenfolge von interne Transaktionen bleiben erhalten. Diese Lösung bringt eine Reihe von Designbeschränkungen mit sich. Beispielsweise ist ˜txpre nicht möglich Gehen Sie davon aus, dass ˜txSC und ˜txpost ausgeführt werden. Darüber hinaus sollte SC so gestaltet sein Führen Sie die Transaktionen „txSC“ und „txpost“ im Namen eines bestimmten Benutzers aus, obwohl dies der Fall wargesendet von FSS. Aus diesen Gründen die grobkörnigere „Strong Atomicity“-Lösung Das oben Gesagte ist in der Praxis wahrscheinlich vorzuziehen. Zur Berücksichtigung komplexerer Abhängigkeiten, die mehrere Transaktionen umfassen und Ihre jeweiligen internen Transaktionen kann der Transaktionsplaner von FSS enthalten ausgefeilte Funktionen, die denen in relationalen Transaktionsmanagern ähneln Datenbankmanager. 5.3 Faire Transaktionssequenzierung Hier diskutieren wir zwei Vorstellungen von Fairness für die Transaktionssequenzierung und die entsprechenden Implementierungen, die durch FSS realisiert werden können: Auftragsfairness basierend auf einer Richtlinie durch FSS auferlegt und sichere Kausalitätserhaltung, die zusätzliche kryptografische Methoden in FSS erfordert. Ordnungsgerechtigkeit: Ordnungsgerechtigkeit ist ein Begriff der zeitlichen Gerechtigkeit in Konsensprotokollen Dies wurde erstmals von Kelkar et al. offiziell eingeführt. [144]. Kelkar et al. Ziel ist es, eine Form der natürlichen Politik zu erreichen, in der Transaktionen stattfinden Die Reihenfolge richtet sich nach dem Zeitpunkt, zu dem sie zum ersten Mal vom DON (oder dem P2P-Netzwerk) empfangen werden. im Fall eines Mempool-basierten FSS). In einem dezentralen System jedoch anders Knoten sehen möglicherweise, dass Transaktionen in einer anderen Reihenfolge eintreffen. Erstellen einer Gesamtordnung Bei allen Transaktionen wird genau das Problem durch das zugrunde liegende Konsensprotokoll gelöst HAUPTKETTE. Kelkar et al. [144] führt daher eine schwächere Vorstellung ein, die sein kann Dies wird mit Hilfe eines dezentralen Oracle-Netzwerks erreicht, das als „Block-Order-Fairness“ bezeichnet wird. Es gruppiert die Transaktionen, die der DON während eines Zeitintervalls empfangen hat, in einem „Block“ und fügt alle Transaktionen des Blocks gleichzeitig und an derselben Position ein (d. h. Höhe) in MAINCHAIN. Sie sind somit zusammen angeordnet und müssen ausführbar sein parallel, ohne dass es zu Konflikten zwischen ihnen kommt. Grob gesagt besagt Orderfairness dann, dass, wenn ein großer Teil der Knoten die Transaktion τ1 vor τ2 sieht, dann τ1 wird vor oder im selben Block wie τ2 sequenziert. Durch die Auferlegung einer solchen Grobheit Durch die Granularität der Transaktionsreihenfolge werden die Möglichkeiten für Front-Running- und andere auftragsbezogene Angriffe erheblich reduziert. Kelkar et al. schlagen eine Familie von Protokollen namens Aequitas [144] vor, die sich mit folgenden Themen befassen: Verschiedene Bereitstellungsmodelle, einschließlich synchroner, teilweise synchroner und asynchroner Netzwerkeinstellungen. Aequitas-Protokolle verursachen im Vergleich zum grundlegenden BFT-Konsens einen erheblichen Kommunikationsaufwand und sind daher für den praktischen Einsatz nicht ideal. Wir gehen jedoch davon aus, dass praktische Varianten von Aequitas entstehen werden, die genutzt werden können für die Transaktionssequenzierung in FSS und anderen Anwendungen. Einige verwandte Systeme haben bereits vorgeschlagen, die weniger begleitenden Formalismus und schwächere Eigenschaften aufweisen, z.B. [36, 151, 236], aber bessere praktische Leistung. Diese Vorhaben können unterstützt werden auch im FSS. Es ist auch erwähnenswert, dass der Begriff „Fairness“ an anderer Stelle im blockchain vorkommt. Literatur mit einer anderen Bedeutung, nämlich Fairness im Sinne von Chance fürBergleute proportional zu ihren zugesagten Ressourcen [106, 181] oder für validators der Chancengleichheit [153]. Sichere Kausalitätserhaltung: Der bekannteste Ansatz zur Verhinderung von Frontrunning und anderen Ordnungsverstößen auf verteilten Plattformen basiert auf Kryptografie Techniken. Ihr gemeinsames Merkmal besteht darin, die Transaktionsdaten selbst zu verbergen und darauf zu warten die Reihenfolge auf der Konsensebene festgelegt wurde und die Transaktionsdaten offengelegt werden später zur Bearbeitung. Dadurch bleibt die kausale Reihenfolge zwischen den Transaktionen erhalten ausgeführt durch den blockchain. Die relevanten Sicherheitskonzepte und kryptografischen Protokolle wurden erheblich vor dem Aufkommen von blockchains entwickelt [71, 190]. Die Sicherheitsbedingungen „Eingabekausalität“ [190] und „sichere Kausalitätserhaltung“ [71, 97] erfordern formal, dass keine Informationen über eine Transaktion bekannt werden bevor die Position dieser Transaktion in der globalen Ordnung bestimmt wurde. Bis zu diesem Zeitpunkt darf ein Gegner nicht in der Lage sein, kryptografisch auf Informationen zu schließen starker Sinn. Man kann vier kryptografische Techniken zur Wahrung der Kausalität unterscheiden: • Commit-Reveal-Protokolle [29, 142, 145]: Anstelle einer Ankündigung einer Transaktion Im Klartext wird nur eine kryptografische Verpflichtung zur Transaktion übertragen. Nachdem alle festgeschriebenen, aber versteckten Transaktionen angeordnet wurden (Anfang blockchain Systeme auf MAINCHAIN selbst, hier jedoch durch FSS), muss der Absender das Commitment öffnen und die Transaktionsdaten innerhalb eines vorgegebenen Zeitintervalls offenlegen. Das Netzwerk überprüft dann, ob die Eröffnung die frühere Verpflichtung erfüllt. Die Die Ursprünge dieser Methode liegen vor dem Aufkommen von blockchains. Obwohl dieser Ansatz besonders einfach ist, bringt er erhebliche Nachteile mit sich und ist aus zwei Gründen nicht einfach anzuwenden. Erstens, da auf der Ebene des Bestellprotokolls nur die Verpflichtung besteht, die Semantik der Transaktion kann im Konsens nicht validiert werden. Eine zusätzliche Hin- und Rückfahrt zum Kunden ist erforderlich. Schwerwiegender wiegt jedoch die Möglichkeit, dass es zu keiner Öffnung kommen könnte jemals eintreffen, was einem Denial-of-Service-Angriff gleichkommen könnte. Darüber hinaus ist es Es ist schwierig zu bestimmen, ob die Eröffnung in einem konsistenten, verteilten Zustand gültig ist denn alle Beteiligten müssen sich darüber einig sein, ob die Eröffnung zustande kommt Zeit. • Commit-Reveal-Protokolle mit verzögerter Wiederherstellung [145]: Eine Herausforderung mit dem Der Commit-Reveal-Ansatz besteht darin, dass sich ein Kunde spekulativ auf eine Transaktion festlegen und diese später nur dann offenlegen kann, wenn nachfolgende Transaktionen sie profitabel machen. A Eine neuere Variante des Commit-Reveal-Ansatzes verbessert die Widerstandsfähigkeit dagegen Art von Fehlverhalten. Insbesondere das TEX-Protokoll [145] behebt dieses Problem Dabei kommt ein cleverer Ansatz zum Einsatz, bei dem verschlüsselte Transaktionen einen Entschlüsselungsschlüssel enthalten erhältlich durch Berechnung einer verifizierbaren Verzögerungsfunktion (VDF) [53, 221]. Wenn ein Kunde Gelingt es ihr nicht, ihre Transaktion rechtzeitig zu entschlüsseln, werden andere im System sie entschlüsseln Dies geschieht in ihrem Namen, indem sie ein mittelschweres kryptografisches Rätsel löst.• Schwellenwertverschlüsselung [71, 190]: Diese Methode nutzt die Funktion von DON aus kryptografische Schwellenwertoperationen. Angenommen, FSS unterhält eine öffentliche Verschlüsselung key pkO und die oracles teilen sich den entsprechenden privaten Schlüssel. Clients verschlüsseln dann Transaktionen unter pkO und senden sie an FSS. FSS-Bestellungen Transaktionen auf dem DON, entschlüsselt sie dann und fügt sie schließlich ein MAINCHAIN in der festen Reihenfolge. Die Verschlüsselung stellt daher sicher, dass die Bestellung erfolgt nicht auf dem Transaktionsinhalt basieren, sondern darauf, dass die Daten selbst wann verfügbar sind benötigt. Diese Methode wurde ursprünglich von Reiter und Birman [190] vorgeschlagen und später von Cachin et al. verfeinert. [71], wo es mit einem genehmigten Konsens integriert wurde Protokoll. Neuere Arbeiten haben die Verwendung der Schwellenwertkryptographie als a Mechanismus auf Konsensebene für generische Nachrichten [33, 97] und für allgemeine Berechnungen mit gemeinsam genutzten Daten [41]. Im Vergleich zu Commit-Reveal-Protokollen verhindert die Schwellenwertverschlüsselung einfache Denial-of-Service-Angriffe (obwohl angesichts des Rechenaufwands der Entschlüsselung Vorsicht geboten ist). Es lässt den DON autonom, in seiner eigenen Geschwindigkeit und ohne zu fahren Warten auf weitere Aktionen des Kunden. Transaktionen können unmittelbar nach der Entschlüsselung validiert werden. Darüber hinaus verschlüsseln Kunden alle Transaktionen mit einem Schlüssel für DON und das Kommunikationsmuster bleibt das gleiche wie bei anderen Transaktionen. Verwalten Sie den Schwellenwertschlüssel sicher und mit wechselnden Knoten O kann jedoch zusätzliche Schwierigkeiten bereiten. • Committed Secret Sharing [97]: Anstatt die Transaktionsdaten zu verschlüsseln Ein Schlüssel, der von DON gehalten wird. Der Client kann ihn auch geheim für die Knoten in O freigeben. Die Transaktion wird mithilfe eines hybriden, rechnerisch sicheren Schemas zur gemeinsamen Nutzung von Geheimnissen durchgeführt wird zunächst mit einer symmetrischen Verschlüsselung mit einem Zufallsschlüssel verschlüsselt. Nur der entsprechende symmetrische Schlüssel wird geteilt und der Chiffretext wird an DON übermittelt. Der Client muss mithilfe einer separat verschlüsselten Nachricht eine Schlüsselfreigabe an jeden Knoten in O senden. Die übrigen Protokollschritte sind die gleichen wie beim Schwellenwert Verschlüsselung, mit der Ausnahme, dass die Transaktionsdaten mit der symmetrischen Entschlüsselung erfolgen Algorithmus nach der Rekonstruktion des Schlüssels pro Transaktion aus seinen Anteilen. Für diese Methode ist keine Einrichtung oder Verwaltung eines Public-Key-Kryptosystems erforderlich im Zusammenhang mit DON. Die Clients müssen jedoch die Knoten in kennen O und kommunizieren Sie in einem sicheren Kontext mit jedem von ihnen, der Orte zusätzliche Belastung für die Kunden. Allerdings bieten die kryptografischen Verfahren einen vollständigen Schutz vor Informationen Da die übermittelten Transaktionen an das Netzwerk weitergegeben werden, verbergen sie keine Metadaten. Für Beispielsweise könnte weiterhin eine IP-Adresse oder eine Ethereum-Adresse des Absenders verwendet werden ein Gegner, der Front-Running- und andere Angriffe ausführen kann. Verschiedene Datenschutzverbesserungen Techniken, die auf der Netzwerkebene eingesetzt werden, z. B. [52, 95, 107], oder auf der Transaktionsebene, B. [13, 65], wäre erforderlich, um dieses Ziel zu erreichen. Die Wirkung eines bestimmten Stückes von Metadaten, nämlich an welchen Vertrag eine Transaktion gesendet wird, kann (teilweise) verschleiert werdendurch Multiplexing vieler Verträge auf demselben DON. Kryptografische Verschleierung von Transaktionen per se verhindert auch nicht die Priorisierung von Transaktionen durch beschädigte Personen DON Knoten in Absprache mit Transaktionssendern. Sichere Kausalität, wie sie durch kryptografische Protokolle garantiert wird, ergänzt die Orderfairness-Garantien für jede Richtlinie, und wir beabsichtigen, eine Kombination aus beiden zu untersuchen Methoden, sofern dies möglich ist. Wenn ein Gegner keinen nennenswerten Vorteil daraus ziehen kann Bei der Beobachtung von Metadaten könnten zusätzlich die sicheren Kausalitätserhaltungsprotokolle verwendet werden auch ein naiver Ordnungsansatz. Beispielsweise können oracle-Knoten Transaktionen schreiben an L, sobald sie sie erhalten, ohne Vervielfältigung. Transaktionen wären dann nach ihrem Aussehen auf L geordnet und anschließend entschlüsselt. Wir planen auch, den Einsatz von TEEs als Möglichkeit zur Durchsetzung einer fairen Ordnung in Betracht zu ziehen; für Beispielsweise kann Tesseract [44] als eine Form der kausalen Ordnung angesehen werden, aber eine gestärkt durch die Fähigkeit des TEE, Transaktionen in expliziter Form zu verarbeiten die Wahrung ihrer Vertraulichkeit. 5.4 Überlegungen zur Netzwerkschicht Bisher hat sich unsere Beschreibung von FSS hauptsächlich auf das Problem der Durchsetzung konzentriert Die endgültige Reihenfolge der Transaktionen stimmt mit der beobachteten Reihenfolge im Netzwerk überein. Im Folgenden Wir berücksichtigen Fairnessprobleme, die auf der Netzwerkebene selbst auftreten könnten. Hochfrequenzhändler auf herkömmlichen elektronischen Marktplätzen investieren erheblich Ressourcen, um eine höhere Netzwerkgeschwindigkeit zu erreichen [64], und Händler an Kryptowährungsbörsen zeigen ein ähnliches Verhalten [90]. Die Netzwerkgeschwindigkeit bietet in beiden Bereichen einen Vorteil Beobachtung der Transaktionen anderer Parteien und Einreichung konkurrierender Transaktionen. Ein in der Praxis eingesetztes und im Buch Flash Boys [155] populär gemachtes Mittel ist der „Speedbump“, der ursprünglich an der IEX-Börse [128] und später an anderen eingeführt wurde tauscht [179] aus (mit gemischten Ergebnissen [19]). Dieser Mechanismus führt zu einer Verzögerung (350 Mikrosekunden bei IEX) beim Marktzugang, mit dem Ziel, Vorteile in zu neutralisieren Geschwindigkeit. Empirische Belege, z.B. [128], unterstützt seine Wirksamkeit bei der Reduzierung bestimmter Handelsaktivitäten Kosten für normale Anleger. FSS kann einfach zur Implementierung einer Asymmetrie verwendet werden Speedbump – einer, der eingehende Transaktionen verzögert. Budish, Cramton und Shim [64] argumentieren, dass Geschwindigkeitsvorteile ausgenutzt werden ist in zeitkontinuierlichen Märkten unausweichlich und plädiert für eine strukturelle Abhilfe in der Form von Batch-Auktions-basierten Märkten. Dieser Ansatz hat sich jedoch nicht allgemein durchgesetzt in bestehenden Handelsplattformen. Herkömmliche Handelssysteme sind zentralisiert und empfangen Transaktionen typischerweise über sie eine einzige Netzwerkverbindung. In einem dezentralen System ist dies hingegen möglich Beobachten Sie die Transaktionsausbreitung aus mehreren Blickwinkeln. Folglich ist es möglich, Verhaltensweisen wie Netzwerkflooding in einem P2P-Netzwerk zu beobachten. Wir beabsichtigen Erforschung von FSS-Ansätzen auf Netzwerkebene, die Entwicklern bei der Festlegung von Richtlinien helfen Verbot solcher unerwünschten Netzwerkverhalten.5.5 Fairness-Richtlinien auf Unternehmensebene Ordnungsgerechtigkeit und sichere Kausalität zielen darauf ab, eine Anordnung bei Transaktionen durchzusetzen, die respektiert den Zeitpunkt, zu dem sie erstellt und erstmals an das Netzwerk übermittelt wurden. Eine Einschränkung dieses Fairness-Gedankens besteht darin, dass er Angriffe eines Gegners nicht verhindert verschafft sich einen Vorteil, indem es ein System mit vielen Transaktionen überschwemmt, eine beobachtete Strategie in freier Wildbahn als eine Möglichkeit, effektives Transaktions-Sniping in token Verkäufen [159] durchzuführen und zu Es kommt zu einer Überlastung, die zur Liquidation von Collateralized Debt Positions (CDPs) führt [48]. Mit anderen Worten: Order-Fairness erzwingt Fairness in Bezug auf Transaktionen, nicht in Bezug auf Spieler. Wie im CanDID-System [160] gezeigt, ist es möglich, oracle-Tools wie DECO zu verwenden oder Town Crier in Verbindung mit einem Knotenkomitee (z. B. DON) zu erreichen verschiedene Formen der Sybil-Resistenz bei gleichzeitigem Schutz der Privatsphäre. Benutzer können Identitäten registrieren und Beweise für ihre Einzigartigkeit liefern, ohne die Identitäten selbst preiszugeben. Sybil-resistente Anmeldeinformationen bieten einen möglichen Ansatz zur Bereicherung der Transaktionsbestellung Richtlinien so zu gestalten, dass die Möglichkeiten für Flooding-Angriffe eingeschränkt werden. Zum Beispiel ein token Der Verkauf erlaubt möglicherweise nur eine Transaktion pro registriertem Benutzer, wenn die Registrierung erfolgt erfordert einen Nachweis der Einzigartigkeit einer nationalen Kennung, beispielsweise einer Sozialversicherungsnummer. Ein solcher Ansatz ist nicht narrensicher, kann sich aber als nützliche Strategie zur Eindämmung von Transaktionsüberflutungsangriffen erweisen.

Das DON Transaktionsausführungs-Framework

(DON-TEF) DONs wird oracle und dezentrale Ressourcenunterstützung für Layer-2-Lösungen bereitstellen was wir das Decentralized Oracle Network Transaction-Execution Framework (DONTEF) oder kurz TEF nennen. Heutzutage ist die Häufigkeit der Aktualisierungen von DeFi-Verträgen durch Latenzen in der Hauptkette begrenzt. z. B. das durchschnittliche Blockintervall von 10–15 Sekunden in Ethereum [104] – sowie die Kosten dafür Schieben großer Datenmengen in die Kette und begrenzter Rechen-/Übertragungsdurchsatz – Motivierende Skalierungsansätze wie Sharding [148, 158, 232] und Layer-2-Ausführung [5, 12, 121, 141, 169, 186, 187]. Sogar blockchains mit viel schnelleren Transaktionszeiten, B. [120], haben Skalierungsstrategien vorgeschlagen, die Off-Chain-Berechnungen beinhalten [168]. TEF soll als Layer-2-Ressource für solche Layer-1-/MAINCHAIN-Systeme fungieren. Mit TEF können DONs schnellere Aktualisierungen in einem MAINCHAIN-Vertrag unterstützen Beibehaltung der wichtigsten Vertrauensgarantien der Hauptkette. TEF kann unterstützen eine von mehreren Layer-2-Ausführungstechniken und -Paradigmen, einschließlich rollups,11 optimistische rollups, Validium usw. sowie ein Schwellenwert-Vertrauensmodell, bei dem DON Knoten führen Transaktionen aus. Der TEF ergänzt den FSS und soll ihn unterstützen. Mit anderen Worten, jeder Anwendungen, die im TEF ausgeführt werden, können FSS verwenden. 11Oft als „zk-rollups“ bezeichnet, eine Fehlbezeichnung, da sie nicht unbedingt wissensfreie Beweise benötigen.

6.1 TEF-Übersicht Der TEF ist ein Entwurfsmuster für die Konstruktion und Ausführung eines leistungsstarken Hybrids smart contract SC. Gemäß der Grundidee hinter hybriden smart contracts umfasst TEF a Zerlegung von SC in zwei Teile: (1) Was wir im TEF-Kontext einen Anker nennen Vertrag SCa auf MAINCHAIN und (2) DON Logikausführung, die wir als ausführbare TEF-Datei bezeichnen. Wir verwenden SC hier, um den logischen Vertrag zu bezeichnen, der durch die Kombination von SCa implementiert wird und ausführen. (Wie oben erwähnt, erwarten wir die Entwicklung von Compiler-Tools zum Zerlegen von a Vertrags-SC automatisch in diese Komponenten ein.) Die ausführbare TEF-Datei exect ist die Engine, die Benutzertransaktionen in SC verarbeitet. Es kann performant ausgeführt werden, da es auf dem DON läuft. Es hat mehrere Funktionen: • Transaktionsaufnahme: exect empfängt oder ruft die Transaktionen der Benutzer ab. Es kann dies tun direkt, d. h. durch Transaktionseinreichung am DON, oder über die MAINCHAIN Mempool mit MS. • Schnelle Transaktionsausführung: Exect verarbeitet Transaktionen mit darin enthaltenen Vermögenswerten SC. Dies geschieht lokal, d. h. auf dem DON. • Schneller und kostengünstiger oracle / Adapterzugriff: exect hat nativen Zugriff auf oracle-Berichte und andere Adapterdaten, die beispielsweise zu schnelleren, günstigeren und genaueren Assets führen Preisgestaltung als MAINCHAIN-Ausführung. Darüber hinaus verringert sich der Off-Chain-Zugriff auf oracle die Betriebskosten des oracle, also die Kosten für die Nutzung des Systems, durch Vermeidung teurer On-Chain-Speicher. • Synchronisierung: exect verschiebt regelmäßig Updates von DON auf MAINCHAIN ​​und aktualisiert SCa. Der Ankervertrag ist das MAINCHAIN-Frontend von SC. Als höher vertrauenswürdige Komponente von SC dient es mehreren Zwecken: • Vermögensverwahrung: Die Gelder der Benutzer werden bei SCa eingezahlt, dort gehalten und von dort abgehoben. • Synchronisierungsüberprüfung: SCa kann bei der Ausführung die Richtigkeit von Statusaktualisierungen überprüfen synchronisiert z. B. SNARKs, die an rollups angehängt sind. • Leitplanken: SCa kann Bestimmungen zum Schutz vor Korruption oder Ausfällen enthalten in Ausführung. (Weitere Einzelheiten finden Sie in Abschnitt 7.) Bei TEF werden die Gelder der Benutzer auf MAINCHAIN verwahrt, was bedeutet, dass DON selbst nicht verwahrt wird. Abhängig von der Wahl des Synchronisierungsmechanismus (siehe unten) benötigen Benutzer möglicherweise Folgendes Vertrauen Sie DON nur für genaue oracle-Berichte und eine zeitnahe Synchronisierung mit MAINCHAIN. Das resultierende Vertrauensmodell ist dem für Orderbuch-basierte DEXes sehr ähnlich, z. B. [2], die heute im Allgemeinen eine Off-Chain-Komponente für den Orderabgleich und eine On-Chain-Komponente für Clearing und Settlement umfassen.Um das Vokabular von Zahlungssystemen zu verwenden, kann man sich exect als Komponente vorstellen von SC ist für das Clearing zuständig, während SCa für die Abwicklung zuständig ist. Eine schematische Darstellung finden Sie in Abb. 13 Darstellung von TEF. Abbildung 13: TEF-Schema. In diesem Beispiel durchlaufen Transaktionen den Mempool von MAINCHAIN per MS an den DON. TEF-Vorteile: TEF bietet drei Hauptvorteile: • Hohe Leistung: SC erbt den viel höheren Durchsatz von DON als MAINCHAIN sowohl für Transaktionen als auch für oracle-Berichte. Darüber hinaus kann exect Transaktionen schneller verarbeiten und zeitnaher auf oracle-Berichte reagieren als eine Implementierung allein auf MAINCHAIN. • Niedrigere Gebühren: Der Synchronisierungsprozess ist weniger zeitkritisch als die Transaktionsverarbeitung und Transaktionen können stapelweise von DON an MAINCHAIN ​​gesendet werden. Folglich sind die On-Chain-Gebühren pro Transaktion (z. B. Gaskosten) bei diesem Ansatz viel niedriger als bei einem Vertrag, der nur auf MAINCHAIN ​​läuft. • Vertraulichkeit: Die Vertraulichkeitsmechanismen des DON können genutzt werden Bär auf SC.

TEF-Einschränkungen: Eine Einschränkung von TEF besteht darin, dass es keine sofortige Unterstützung bietet Auszahlungen, da sie nur auf MAINCHAIN erfolgen: Beim Senden einer Auszahlungsanfrage Für SCa muss ein Benutzer möglicherweise auf Exect warten, um eine Statusaktualisierung durchzuführen, die Folgendes enthält Auszahlungstransaktion, bevor sie genehmigt werden kann. Wir diskutieren einige Teillösungen, jedoch in Abschnitt 6.2. Eine weitere Einschränkung von TEF besteht darin, dass es die atomare Zusammensetzung von DeFi nicht unterstützt. Verträge auf MAINCHAIN, insbesondere die Möglichkeit, Vermögenswerte über mehrere DeFi zu leiten Verträge in einer einzigen Transaktion. TEF kann jedoch eine solche Atomizität unterstützen DeFi Verträge, die auf demselben DON laufen. Wir besprechen auch einige Möglichkeiten, dieses Problem anzugehen Problem in Abschnitt 6.2. 6.2 Transaktionsrouting Transaktionen für SC können von Benutzern direkt an DON gesendet oder weitergeleitet werden der Mempool in MAINCHAIN (über FSS). Es gibt jeweils vier verschiedene Transaktionstypen davon erfordert eine unterschiedliche Handhabung: Vertragsinterne Transaktionen: Da es die Komplikationen der Gasdynamik umgeht, bietet TEF SC mehr Flexibilität bei der Abwicklung von Transaktionen, als dies der Fall wäre verfügbar in einem Layer-1-Vertrag. Beispielsweise während einer Mempool-Transaktion in Ethereum kann durch eine neue Transaktion mit einem höheren Gaspreis überschrieben werden. SC kann eine Transaktion, die Vermögenswerte innerhalb von SC betrifft, als maßgeblich behandeln, sobald sie sichtbar wird im Mempool. Folglich muss SC nicht auf die Bestätigung einer Transaktion warten innerhalb eines Blocks, was zu einer erheblich reduzierten Latenz führt. Proxying: Ein Benutzer möchte möglicherweise eine Transaktion τ über einen Wallet-Vertrag oder an SC senden anderer Vertrag auf MAINCHAIN. Es ist möglich, dass DON die Ausführung von simuliert τ auf MAINCHAIN, um zu bestimmen, ob es zu einer Folgetransaktion zu SC führt. Wenn ja, kann τ mit anderen Transaktionen für SC, die dies tun, sequenziert werden. Es gibt einige Möglichkeiten, wie der DON solche Transaktionen identifiziert: (1) Der DON kann simulieren alle Transaktionen im Mempool (ein teurer Ansatz); (2) Bestimmte Verträge bzw Vertragstypen, z. B. Wallets, können zur Überwachung durch DON aufgelistet werden; oder (3) Benutzer können Kommentieren Sie Transaktionen für die DON-Inspektion. Die Sache wird komplizierter, wenn eine einzelne Transaktion mit zwei Transaktionen interagiert Verträge, SC1 und SC2, die beide Fair Sequencing Services nutzen und inkompatible Bestellrichtlinien haben. Der DON könnte beispielsweise τ zum spätesten Zeitpunkt sequenzieren das ist mit beidem kompatibel. Einlagen: Eine Transaktion, bei der ein MAINCHAIN-Vermögenswert in SC eingezahlt wird, muss in einem Block bestätigt werden, bevor SC sie als gültig betrachten kann. Wenn es den Abbau von a erkennt Bei einer Transaktion, die Vermögenswerte (z. B. Ether) an SCa sendet, kann exect dies sofort bestätigenKaution. Beispielsweise kann ein aktueller oracle-gemeldeter Preis für den DON auf den angewendet werden Vermögenswert. Auszahlungen: Wie oben erwähnt besteht eine Einschränkung von TEF darin, dass Abhebungen nicht immer sofort ausgeführt werden können. In einem Ausführungsmodell vom Typ rollup erfolgt der Rückzug Um sicher zu sein, muss die Anfrage mit anderen Transaktionen sequenziert, d. h. zusammengefasst werden verarbeitet. Es gibt jedoch einige teilweise Abhilfemaßnahmen für diese Einschränkung. Wenn der DON schnell einen rollup Gültigkeitsnachweis bis zur Auszahlungstransaktion berechnen kann, kann die Beobachtung der Transaktion τ eines Benutzers im Mempool-Exect eine Statusaktualisierungstransaktion τ ′ für τ zu einem höheren Gaspreis senden, eine Art vorteilhaftes Front-Running. Vorausgesetzt, dass τ nicht abgebaut wird, bevor τ ′ den Mempool erreicht, geht τ ′ vor τ und τ wird einen genehmigten Widerruf bewirken. In einer TEF-Variante, bei der DON zur Berechnung von Statusaktualisierungen herangezogen wird (siehe Die Schwellenwert-Signaturvariante unten) kann DON alternativ außerhalb der Kette bestimmen ob τ angesichts des Zustands von SC bei seiner Ausführung genehmigt werden sollte. Der DON kann dann eine Transaktion τ ′ senden, die die Auszahlung τ genehmigt – ohne dass eine vollständige Auszahlung erfolgt Zustandsaktualisierung. Wenn dieser Ansatz nicht möglich ist oder in Fällen, in denen er keinen Erfolg hat, wird ein DON eingeleitet Die Transaktion τ ′ kann als Reaktion auf τ Gelder an den Benutzer senden, sodass der Benutzer dies nicht tun muss eine weitere Transaktion einleiten. 6.3 Synchronisierung Die ausführbare TEF-Datei exect verschiebt regelmäßig Aktualisierungen von DON nach MAINCHAIN. Aktualisieren des SCa-Status in einem Prozess, den wir als Synchronisierung bezeichnen. An eine Synchronisierung kann gedacht werden als Weitergabe von Layer-2-Transaktionen an Layer-1, sodass TEF auf eine beliebige Zahl zurückgreifen kann der vorhandenen Techniken für diesen Zweck, einschließlich rollups [5, 12, 16, 69], optimistisch rollups [10, 11, 141], Validium [201] oder grundlegende Schwellenwertsignatur, z. B. Schwellenwert BLS, Schnorr oder ECDSA [24, 54, 116, 202]. Im Prinzip vertrauenswürdige Ausführungsumgebungen kann auch die Korrektheit von Zustandsänderungen bestätigen und bietet so eine wesentlich höhere Leistung Alternative zu rollups, jedoch mit einem hardwareabhängigen Vertrauensmodell. (Siehe z. B. [80].) Im Folgenden vergleichen wir diese Synchronisierungsoptionen im Hinblick auf drei Schlüsseleigenschaften TEF: • Datenverfügbarkeit: Wo wird der Zustand von SC gespeichert? Es gibt mindestens drei Optionen verfügbar in TEF: auf der MAINCHAIN, auf einem DON oder durch einen Speicher eines Drittanbieters Anbieter wie IPFS. Sie erreichen unterschiedliche Sicherheitsgarantien, Verfügbarkeit Leistungsniveaus und Leistungsprofile. Kurz gesagt, das Speichern des Status auf der MAINCHAIN ermöglicht Überprüfbarkeit in der Kette und macht die Abhängigkeit von einer Partei für die staatliche Verfügbarkeit überflüssig; Andererseits kann die Speicherung des Zustands außerhalb der Kette die Speicherkosten senken und verbessern Durchsatz, auf Kosten vertrauenswürdiger Speicheranbieter (DON oder Dritter) für Datenverfügbarkeit. Natürlich gibt es auch flexible Modelle, die diese Optionen kombinieren möglich. Die erforderliche Form der Datenverfügbarkeit geben wir in Tabelle 1 an.• Korrektheitsgarantien: Wie stellt SCa die Korrektheit der Aktualisierungen fest? von exect gepusht? Dies wirkt sich auf die Rechenlast auf exect und SCa aus Synchronisierungslatenz (siehe unten). • Latenz: Die Synchronisierungslatenz hat drei Einflussfaktoren: (1) Die benötigte Zeit für exect, um eine Synchronisierungstransaktion τsync zu generieren; (2) Die für τsync benötigte Zeit muss auf MAINCHAIN bestätigt werden; und (3) Die Zeit, die τsync benötigt, um wirksam zu werden SCa. Bei TEF ist die Latenz besonders wichtig für Abhebungen (jedoch weniger für vertragsinterne Transaktionen), da Abhebungen zwangsläufig eine (mindestens) erfordern teilweise) Zustandssynchronisierung. Synchronisierung Optionen Daten Verfügbarkeit Korrektheit Garantien Latenz Rollup [5, 12, 16, 69] An der Kette Gültigkeitsnachweise Für die Generierung benötigte Zeit Gültigkeitsnachweise (z. B. Protokolle in aktuellen Systemen) Validium [201] Off-Chain Gültigkeitsnachweise Das Gleiche wie oben Optimistisch rollup [10, 11, 141] An der Kette Betrugsbeweise Länge der Herausforderung Zeitraum (z. B. Tage oder Wochen) Schwellenwertsignierung [24, 54, 116, 202] Flexibel Schwellenwertsignaturen von DON Sofort Vertrauenswürdige Ausführungsumgebungen [80] Flexibel Hardwarebasiert Bescheinigungen Sofort Tabelle 1: Verschiedene Synchronisierungsoptionen in TEF und ihre Eigenschaften. Tabelle 1 fasst diese Eigenschaften in den fünf Hauptsynchronisierungsoptionen in TEF zusammen. (Hinweis dass wir nicht beabsichtigen, diese Technologien als eigenständige Layer-2-Skalierung zu vergleichen Lösungen. Hierzu verweisen wir die Leser z. B. auf [121].) Jetzt besprechen wir jede Synchronisierungsoption. Rollups: Ein rollup [69] ist ein Protokoll, in dem der durch a bewirkte Zustandsübergang erfolgt Der Transaktionsstapel wird außerhalb der Kette berechnet. Die Zustandsänderung wird dann propagiert auf MAINCHAIN. Um rollups zu implementieren, speichert der Anker smart contract SCa eine kompakte Darstellung Rstate (z. B. eine Merkle-Wurzel) des tatsächlichen Zustands. Zum Synchronisieren sendet exect τsync = (T, R′ Zustand) an SCa, wobei T die Menge der Transaktionen ist, die es seit der letzten verarbeitet hatsync und R′ state ist die kompakte Darstellung des durch Anwendung berechneten neuen Zustands Transaktionen in T in den vorherigen Zustand Rstate. Es gibt zwei beliebte Varianten, die sich darin unterscheiden, wie SCa Statusaktualisierungen in τsync überprüft. Die ersten, (zk-)rollups, fügen ein prägnantes Argument der Korrektheit hinzu, manchmal auch „ ein Gültigkeitsbeweis für den Übergang Rstate →R′ Staat. Um diese Variante zu implementieren, exect berechnet und übermittelt den Gültigkeitsnachweis (z. B. einen zk-SNARK-Beweis) zusammen mit τsync, beweisen, dass R′ Der Zustand ist das Ergebnis der Anwendung von T auf den aktuellen Zustand von SCa. Der Anker Der Vertrag akzeptiert die Statusaktualisierung erst, nachdem er den Beweis überprüft hat. Optimistische rollups enthalten keine Korrektheitsargumente, haben aber staking und Challenge-Prozeduren, die die verteilte Verifizierung von Zustandsübergängen erleichtern. Dafür rollup Variante, SCa akzeptiert vorläufig τsync unter der Annahme, dass es korrekt ist (daher der Optimismus) aber τsync wird erst nach einer Herausforderungsperiode wirksam, in der jede Partei Die Überwachung von MAINCHAIN kann fehlerhafte Statusaktualisierungen identifizieren und SCa zur Durchführung informieren Notwendige Aktionen (z. B. um den Status zurückzusetzen und eine Strafe für exect zu verhängen.) Beide rollup-Varianten erreichen die Datenverfügbarkeit in der Kette, wenn Transaktionen gebucht werden On-Chain, aus dem der vollständige Zustand erstellt werden kann. Die Latenz von zk-rollups beträgt dominiert von der Zeit, die zum Generieren von Gültigkeitsnachweisen benötigt wird, die typischerweise auf dem liegt Reihenfolge von Minuten in bestehenden Systemen [16] und wird im Laufe der Zeit wahrscheinlich Verbesserungen erfahren. Optimistische rollups hingegen haben eine höhere Latenz (z. B. Tage oder Wochen) denn der Anfechtungszeitraum muss lang genug sein, damit Betrugsnachweise funktionieren. Die Die Bedeutung einer langsamen Bestätigung ist subtil und manchmal spezifisch für das Schema Eine gründliche Analyse würde den Rahmen sprengen. Bestimmte Systeme sehen beispielsweise eine Zahlung vor Transaktionen als „vertrauenswürdig endgültig“ [109], bevor die Statusaktualisierung bestätigt wird, da a Ein normaler Benutzer könnte einen rollup viel schneller verifizieren als den MAINCHAIN. Validium: Validium ist eine Form von (zk-)rollup, die Daten nur außerhalb der Kette verfügbar macht und verwaltet nicht alle Daten auf MAINCHAIN. Konkret sendet exect nur das Neue Zustand und der Nachweis, jedoch keine Transaktionen an SCa. Mit Synchronisierung im Validium-Stil, exect und der DON, der es ausführt, sind die einzigen Parteien, die den vollständigen Zustand speichern und die Transaktionen ausführen. Wie bei zk-rollups wird die Synchronisierungslatenz von der Gültigkeit dominiert Beweisgenerierungszeit. Im Gegensatz zu zk-rollups reduziert die Synchronisierung im Validium-Stil jedoch die senkt die Lagerkosten und erhöht den Durchsatz. Schwellenwertsignierung durch DON: Angenommen, ein Schwellenwert von DON Knoten ist ehrlich, a Eine einfache und schnelle Synchronisierungsoption besteht darin, dass DON Knoten den neuen Status gemeinsam signieren. Dieser Ansatz kann sowohl die Datenverfügbarkeit in der Kette als auch außerhalb der Kette unterstützen. Beachten Sie, dass wenn Benutzer vertrauen DON für oracle-Updates, sie müssen ihm nicht mehr vertrauen, um sie zu akzeptieren Zustandsaktualisierungen, da sie sich bereits in einem Schwellenwert-Vertrauensmodell befinden. Ein weiterer Vorteil von Die Schwellenwertsignatur weist eine geringe Latenz auf. Unterstützung für neue Transaktionssignaturformate wie vorgeschlagen in EIP-2938 [70] und bekannt als Kontoabstraktion würde Schwellenwert bilden Die Unterzeichnung ist wesentlich einfacher umzusetzen, da dadurch die Notwendigkeit einer Schwelle entfällt ECDSA, das wesentlich komplexere Protokolle beinhaltet (z. B. [116, 117, 118])als Alternativen wie Schwellenwert-Schnorr-Signaturen [202] oder BLS-Signaturen [55]. Vertrauenswürdige Ausführungsumgebungen (TEEs): TEEs sind isolierte Ausführungsumgebungen (normalerweise durch Hardware realisiert), die einen starken Sicherheitsschutz bieten sollen für darin laufende Programme. Einige TEEs (z. B. Intel SGX [84]) können Proofs erstellen, sogenannte Bescheinigungen, die besagen, dass eine Ausgabe von einem bestimmten Programm korrekt berechnet wurde eine bestimmte Eingabe12. Eine TEE-basierte Variante der TEF-Synchronisierung kann implementiert werden durch Ersetzen von Beweisen in (zk-)rollups oder Validium durch TEE-Bescheinigungen mithilfe von Techniken von [80]. Im Vergleich zu wissensfreien Beweisen, die in rollups und Validium verwendet werden, sind TEEs viel leistungsfähiger. Im Vergleich zur Schwellenwertsignatur verringern TEEs die Komplexität von Generieren von Schwellenwert-ECDSA-Signaturen, da grundsätzlich nur ein TEE vorhanden sein muss beteiligt. Die Verwendung von TEEs führt jedoch zu zusätzlichen hardwareabhängigen Vertrauensannahmen. Man kann TEEs auch mit Schwellenwertsignatur kombinieren, um Resilienz zu schaffen gegen die Kompromittierung eines Bruchteils der TEE-Instanzen, obwohl diese Schutzmaßnahme führt die Komplexität der Generierung von Schwellenwert-ECDSA-Signaturen wieder ein. Zusätzliche Flexibilität: Diese Synchronisierungsoptionen können auf folgende Weise verfeinert werden, um mehr Flexibilität zu bieten. • Flexible Auslösung: Die TEF-Anwendung kann die Bedingungen bestimmen, unter denen Die Synchronisierung wird ausgelöst. Beispielsweise kann die Synchronisierung stapelbasiert erfolgen, z. B. danach erfolgen alle N Transaktionen, zeitbasiert, z. B. alle 10 Blöcke, oder ereignisbasiert, z. B., stattfinden immer dann, wenn sich die Zielpreise für Vermögenswerte erheblich verändern. • Teilweise Synchronisierung: Dies ist möglich und in manchen Fällen wünschenswert (z. B. mit rollups, Eine teilweise Synchronisierung kann die Latenz reduzieren), um beispielsweise eine schnelle Synchronisierung kleiner Dateien zu ermöglichen Zustandsmengen, wobei eine vollständige Synchronisierung möglicherweise nur in regelmäßigen Abständen durchgeführt wird. Zum Beispiel, exect kann eine Auszahlungsanforderung genehmigen, indem es das Guthaben eines Benutzers in SCa aktualisiert ohne anderweitig den MAINCHAIN-Status zu aktualisieren. 6.4 Reorgs Blockchain-Reorganisationen aufgrund von Netzwerkinstabilität oder sogar 51%-Angriffen kann eine Bedrohung für die Integrität einer Hauptkette darstellen. In der Praxis haben Gegner verwendet sie, um Angriffe mit doppelten Ausgaben zu starten [34]. Zwar gibt es solche Angriffe auf große Ketten Die Montage ist schwierig, sie sind jedoch für einige Ketten [88] machbar. Da es unabhängig von MAINCHAIN arbeitet, bietet ein DON das Interessante Möglichkeit der Beobachtung und Bereitstellung einiger Schutzmaßnahmen gegen Reorgs im Zusammenhang mit Angriffe. Beispielsweise kann ein DON einem vertrauenden Vertrag SC auf MAINCHAIN ​​die Existenz eines konkurrierenden Forks mit einer bestimmten Schwellenwertlänge τ melden. Der DON kann zusätzlich 12Ergänzende Details finden Sie im Anhang B.2.1. Sie sind zum Verständnis nicht erforderlich.

liefern den Beweis – entweder in einer PoW- oder PoS-Umgebung – für die Existenz einer solchen Abzweigung. Die Vertrags-SC kann geeignete Abwehrmaßnahmen ergreifen, wie z. B. die Aussetzung weiterer Transaktionsausführungen für einen bestimmten Zeitraum (z. B. um Börsen zu ermöglichen, doppelt ausgegebene Transaktionen auf die schwarze Liste zu setzen). Vermögenswerte). Beachten Sie, dass ein Gegner, der einen 51 %-Angriff durchführt, zwar versuchen kann, zu zensieren Berichte von einem DON, eine Gegenmaßnahme in SC besteht darin, regelmäßige Berichte von zu verlangen DON, um Transaktionen zu verarbeiten (d. h. einen Heartbeat) oder um einen neuen Bericht anzufordern Validieren Sie eine Transaktion mit hohem Wert. Während es sich bei solchen Forking-Warnungen im Prinzip um einen allgemeinen Dienst handelt, den DON anbieten kann Unser Plan besteht darin, sie aus verschiedenen Gründen in den TEF zu integrieren.

Vertrauensminimierung

Als dezentrales System mit Beteiligung einer heterogenen Gruppe von Einheiten ist das Das Chainlink-Netzwerk bietet starken Schutz vor Ausfällen sowohl bei der Liveness (Verfügbarkeit) als auch bei der Sicherheit (Berichtsintegrität). Die meisten dezentralen Systeme unterscheiden sich jedoch darin der Grad, in dem ihre Bestandteile selbst dezentralisiert sind. Dies Dies gilt sogar für große Systeme, in denen die Dezentralisierung zwischen den Bergleuten [32] und begrenzt ist Vermittler [51] gibt es schon lange. Das Ziel jeder Dezentralisierungsbemühung ist die Minimierung des Vertrauens: Wir versuchen, das Vertrauen zu reduzieren nachteilige Auswirkungen systemischer Korruption oder Ausfälle innerhalb des Chainlink-Netzwerks, selbst das aufgrund eines böswilligen DON. Unser Leitprinzip ist das Prinzip der geringsten Privilegien [197]. Systemkomponenten und Akteure innerhalb des Systems sollten über streng begrenzte Berechtigungen verfügen um nur den erfolgreichen Abschluss der ihnen zugewiesenen Rollen zu ermöglichen. Hier stellen wir mehrere konkrete Mechanismen vor, die Chainlink in seinen Antrieb übernehmen kann hin zu einer immer stärkeren Vertrauensminimierung. Wir charakterisieren diese Mechanismen anhand von Begriffen der Loci, also der Systemkomponenten, in denen sie verwurzelt sind, siehe Abb. 14. Wir Behandeln Sie jeden Ort in einem entsprechenden Unterabschnitt. 7.1 Authentifizierung der Datenquelle Aktuelle Betriebsmodelle für oracles werden durch die Tatsache eingeschränkt, dass es nur wenige Datenquellen gibt Signieren Sie die ausgelassenen Daten digital, was zum großen Teil darauf zurückzuführen ist, dass TLS nicht nativ signiert Daten. TLS nutzt digitale Signaturen in seinem „Handshake“-Protokoll (zur Einrichtung). ein gemeinsamer Schlüssel zwischen einem Server und einem Client). HTTPS-fähige Server verfügen daher über Zertifikate auf öffentliche Schlüssel, die prinzipiell zum Signieren von Daten dienen können, diese aber in der Regel nicht nutzen Diese Zertifikate unterstützen die Datensignierung. Folglich ist die Sicherheit eines DON, as In den heutigen oracle-Netzwerken ist es darauf angewiesen, dass oracle-Knoten Daten zuverlässig von einem Datenpunkt weiterleiten Quelle zu einem Vertrag. Ein wichtiger langfristiger Bestandteil unserer Vision zur Vertrauensminimierung in Chainlink ist eine stärkere Datenquellenauthentifizierung durch die Unterstützung von Tools und Standards für die Datensignierung. Das Signieren von Daten kann dazu beitragen, durchgängige Integritätsgarantien durchzusetzen. Im Prinzip gilt: Wenn ein Vertrag als Eingabe ein Datenelement D akzeptiert, das direkt von einem Datenelement signiert wurde

Abbildung 14: Orte der in diesem Abschnitt diskutierten vertrauensminimierenden Mechanismen. 1⃝Daten Quellen stellen Daten an 2⃝DON bereit, der eine Funktion der Daten an eine abhängige Person weiterleitet 3⃝smart contract. Darüber hinaus umfasst das Netzwerk DON oder oracle 4⃝Knoten Management smart contracts auf MAINCHAIN für z. B. Kompensationsknoten, Guard Schienen usw. Quelle, dann kann das Netzwerk oracle D nicht manipulieren. Verschiedene ermutigende Es wurden Bemühungen unternommen, eine solche Signierung von Daten zu ermöglichen, darunter OpenID Connect ist in erster Linie für die Benutzerauthentifizierung konzipiert. [9], TLS-N, ein akademisches Projekt mit dem Ziel Erweitern Sie TLS [191] durch die Umnutzung von TLS-Zertifikaten und TLS-Nachweiserweiterungen [63]. Während OpenID Connect eine gewisse Akzeptanz erfahren hat, gibt es jedoch TLS-Beweiserweiterungen und TLS-N müssen noch eingeführt werden. Eine weitere mögliche Möglichkeit der Datenquellenauthentifizierung besteht darin, die eigene Datenquelle zu verwenden Signierte HTTP-Exchanges (SXG) [230], die sie als Teil des Accelerated Mobile Pages (AMP)-Protokolls [225] in Content-Delivery-Netzwerken zwischenspeichern können. Der mobile Chrome-Browser zeigt den Inhalt von AMP-cacheten SXGs so an, als ob sie von dort bereitgestellt würden die eigenen Netzwerkdomänen ihrer Herausgeber anstelle der Cache-Server-Domäne. Dieser Branding-Anreiz, gepaart mit der relativ einfachen Aktivierung über Dienste wie CloudFlares Real URL [83] und Googles Amppackager [124], könnte zu einer weiten Verbreitung von SXGs in zwischengespeicherten Nachrichteninhalten führen, was eine einfache, manipulationssichere Lösung ermöglichen würde Möglichkeit für Chainlink oracles, bei berichtenswerten Ereignissen auszulösen, die in gültigen SXGs gemeldet werden. Während im AMP-Cache gespeicherte SXGs von Nachrichtenverlegern für Hochgeschwindigkeitsnachrichten nicht nützlich wären B. Berichte über Handelsdaten, könnten sie eine sichere Quelle für benutzerdefinierte Anwendungen sein Verträge im Zusammenhang mit realen Ereignissen wie extremen Wetterbedingungen oder Wahlergebnissen. Wir glauben, dass eine einfache Bereitstellung, ausgereifte Tools und Flexibilität von entscheidender Bedeutung sein werden Beschleunigung der Signierung von Datenquellen. Ermöglicht Datenanbietern die Verwendung von Chainlink-Knoten als Ein authentifiziertes API-Frontend scheint ein vielversprechender Ansatz zu sein. Wir beabsichtigen, eine zu erstellenOption für Knoten, in diesem Modus zu funktionieren, mit oder ohne Teilnahme am Netzwerk als vollwertiges oracle. Wir bezeichnen diese Fähigkeit als authentifizierte Datenherkunft (ADO). Durch die Verwendung von Chainlink-Knoten mit ADO können Datenquellen davon profitieren von den Erfahrungen und Tools, die die Chainlink-Community beim Hinzufügen von Digital entwickelt hat Signierfunktionen für ihre bestehende Suite von Off-Chain-APIs. Sollten sie sich entscheiden zu kandidieren? Wenn sie ihre Knoten als oracles angeben, können sie zusätzlich potenzielle neue Einnahmequellen erschließen nach dem gleichen Modell wie bestehende Datenanbieter, z. B. Kraken [28], Kaiko [140] und andere, die Chainlink-Knoten ausführen, um API-Daten in der Kette zu verkaufen. 7.1.1 Die Einschränkungen der authentifizierten Datenherkunft Die digitale Signatur durch Datenquellen kann zwar zur Stärkung der Authentifizierung beitragen, reicht jedoch per se nicht aus, um alle natürlichen Sicherheits- oder Betriebsziele eines oracle zu erreichen. Netzwerk. Zunächst muss ein bestimmtes Datenelement D dennoch robust und zeitnah weitergeleitet werden Weg von einer Datenquelle zu smart contract oder einem anderen Datenkonsumenten. Das heißt, sogar in Eine ideale Einstellung, bei der alle Daten mit vorprogrammierten abhängigen Schlüsseln signiert werden Verträgen wäre weiterhin ein DON erforderlich, um die Daten zuverlässig aus Quellen zu kommunizieren zu Verträgen. Darüber hinaus gibt es eine Reihe von Fällen, in denen Verträge oder andere oracle-Daten vorliegen Verbraucher möchten Zugriff auf die authentifizierte Ausgabe verschiedener berechneter Funktionen Quelldaten aus zwei Hauptgründen: • Vertraulichkeit: Eine Datenquellen-API kann vertrauliche oder proprietäre Daten bereitstellen Das muss geschwärzt oder bereinigt werden, bevor es in der Kette öffentlich sichtbar gemacht wird. Jede Änderung an signierten Daten machte jedoch die Signatur ungültig. Setzen Sie einen anderen Auf diese Weise sind naives ADO und Datenbereinigung nicht kompatibel. Wir zeigen in Beispiel 3 wie beides durch eine erweiterte Form von ADO in Einklang gebracht werden kann. • Datenquellenfehler: Sowohl Fehler als auch Ausfälle können sich auf Datenquellen auswirken, und digitale Signaturen lösen keines der Probleme. Von Anfang an hat [98], Chainlink Es gibt bereits einen Mechanismus zur Behebung solcher Fehler: Redundanz. Die von oracle-Netzwerken herausgegebenen Berichte stellen typischerweise die kombinierten Daten mehrerer dar Quellen. Wir besprechen nun Schemata, die wir im ADO-Umfeld untersuchen, um die Vertraulichkeit von Quelldaten zu verbessern und Daten aus mehreren Quellen sicher zu kombinieren. 7.1.2 Vertraulichkeit Datenquellen können möglicherweise nicht das gesamte Spektrum der gewünschten APIs vorhersehen und verfügbar machen von Benutzern. Insbesondere möchten Benutzer möglicherweise auf vorverarbeitete Daten zugreifen, um dies sicherzustellen Vertraulichkeit. Das folgende Beispiel verdeutlicht das Problem.Beispiel 3. Alice möchte einen Berechtigungsnachweis für eine dezentrale Identität (DID) erhalten dass sie über 18 Jahre alt ist (und somit beispielsweise einen Kredit aufnehmen kann). Zu tun Daher muss sie diese Tatsache über ihr Alter einem DID-Ausweisaussteller nachweisen. Alice hofft, Daten des Department of Motor Vehicles (DMV) ihres Staates nutzen zu können. Website zu diesem Zweck. Das DMV verfügt über eine Aufzeichnung ihres Geburtsdatums und wird eine aussenden darauf digital signierte Bescheinigung A in folgender Form: A = {Name: Alice, Geburtsdatum: 16.02.1999}. In diesem Beispiel kann die Bescheinigung A ausreichen, damit Alice dem DID den Nachweis erbringen kann Der Aussteller des Ausweises gibt an, dass sie über 18 Jahre alt ist. Es werden jedoch unnötig vertrauliche Informationen preisgegeben: die von Alice genaues DoB. Im Idealfall möchte Alice stattdessen vom DMV eine Unterschrift auf einem einfache Aussage A′, dass „Alice über 18 Jahre alt ist.“ Mit anderen Worten, sie will das Ausgabe einer Funktion G an ihrem Geburtsdatum X, wobei (informell) A′ = G(X) = True if CurrentDate −X ≥18 Jahre; andernfalls ist G(X) = Falsch. Um es zu verallgemeinern: Alice möchte von der Datenquelle eine signierte Datei anfordern können Bescheinigung A′ der Form: A′ = {Name: Alice, Func:G(X), Ergebnis: True}, wobei G(X) eine Spezifikation einer Funktion G und ihrer Eingabe(n) X bezeichnet. Wir stellen uns vor dass ein Benutzer in der Lage sein sollte, bei seiner Anfrage nach a ein gewünschtes G(X) als Eingabe bereitzustellen entsprechende Bescheinigung A′. Beachten Sie, dass die Bescheinigung A′ der Datenquelle die Spezifikation G(X) enthalten muss Stellen Sie sicher, dass A′ richtig interpretiert wird. Im obigen Beispiel definiert G(X) die Bedeutung des booleschen Werts in A′ und somit bedeutet True das Subjekt der Bescheinigung ist über 18 Jahre alt. Wir beziehen uns auf flexible Abfragen, bei denen ein Benutzer G(X) als funktionale Abfragen angeben kann. Um Anwendungsfälle wie den in Beispiel 3 sowie solche mit Abfragen zu unterstützen Direkt aus Verträgen beabsichtigen wir, die Unterstützung bei funktionalen Anfragen einzubeziehen einfache Funktionen G als Teil von ADO. 7.1.3 Quelldaten kombinieren Um die Kosten in der Kette zu senken, sind Verträge im Allgemeinen so konzipiert, dass sie kombinierte Daten verbrauchen aus mehreren Quellen, wie im folgenden Beispiel dargestellt. Beispiel 4 (Medianisierung von Preisdaten). Um einen Preis-Feed bereitzustellen, d. h. den Wert von einem Wenn Sie einen Vermögenswert (z. B. ETH) in Bezug auf einen anderen (z. B. USD) vergleichen, wird ein oracle-Netzwerk im Allgemeinen dies tun Erhalten Sie aktuelle Preise aus verschiedenen Quellen, beispielsweise von Börsen. Das Netzwerk oracle sendet typischerweise den Median dieser Werte an einen abhängigen Vertrags-SC. In einer Umgebung mit Datensignierung erhält man ein korrekt funktionierendes oracle-Netzwerk aus Datenquellen S = {S1, . . . , SnS} eine Folge von Werten V = {v1, v2, . . . , vnS} von nS-Quellen mit zugehörigen quellenspezifischen Signaturen Σ = {σ1, σ2, . . . , σnS}. Auf Nach Überprüfung der Signaturen übermittelt es den Preis v = median(V) an SC.Leider gibt es für ein oracle-Netzwerk keine einfache Möglichkeit, den Median zu übertragen Wert v in Beispiel 4 an SC zusammen mit einem prägnanten Beweis σ∗dass v korrekt berechnet wurde über vorzeichenbehaftete Eingaben. Ein naiver Ansatz wäre, die öffentlichen Schlüssel aller NS-Datenquellen in SC zu kodieren. Das oracle-Netzwerk würde dann (V, Σ) weiterleiten und es SC ermöglichen, den Median von V zu berechnen. Dies würde jedoch zu einem Beweis σ der Größe O(nS) führen – d. h. σ∗ wäre nicht prägnant. Außerdem würden für SC hohe Gaskosten anfallen, da alle Unterschriften überprüft werden müssten Σ. Der Einsatz von SNARKs hingegen ermöglicht einen prägnanten Nachweis korrekt kombinierter authentifizierter Quellwerte. Es mag in der Praxis praktikabel sein, stellt aber einen ziemlich hohen Aufwand dar Rechenkosten für den Prüfer und etwas hohe Gaskosten für die Kette. Verwendung von Town Crier ist ebenfalls eine Möglichkeit, erfordert jedoch die Verwendung von TEEs, was nicht für alle geeignet ist Vertrauensmodelle der Benutzer. Ein hilfreiches Konzept, um Lösungen für das allgemeine Problem des Signierens kombinierter Daten aus Quellen zu finden, ist ein kryptografisches Tool, das als funktionale Signaturen bekannt ist [59, 132]. Kurz gesagt, funktionale Signaturen ermöglichen es einem Unterzeichner, die Signaturfähigkeit zu delegieren, so dass Der Delegierte kann Nachrichten nur im Bereich einer vom Unterzeichner gewählten Funktion F signieren. Wir zeigen in Anhang D, wie diese funktionale Einschränkung zur Begrenzung des Bereichs dienen kann der von einem DON ausgegebenen Berichtswerte als Funktion der von Datenquellen signierten Werte. Wir führen außerdem ein neues Grundelement ein, eine so genannte diskretisierte funktionale Signatur, die eine gelockerte Anforderung an die Genauigkeit beinhaltet, aber möglicherweise viel leistungsfähiger ist als Ansätze wie SNARKs. Das Problem der Kombination von Datenquellen auf eine Weise, die eine Quellenauthentifizierung einschließt der Ausgaben gilt auch für Datenaggregatoren, z. B. CoinCap, CoinMarketCap, CoinGecko, CryptoCompare usw., die Daten von einer Vielzahl von Börsen erhalten, die sie Gewicht basierend auf Volumina, unter Verwendung von Methoden, die sie in einigen Fällen öffentlich machen und in anderen Fällen urheberrechtlich geschützt. Ein Aggregator, der einen Wert veröffentlichen möchte Die Quellauthentifizierung steht vor der gleichen Herausforderung wie die Aggregation einer Sammlung von Knoten Quelldaten. 7.1.4 Quelldaten verarbeiten Anspruchsvolle smart contracts hängen wahrscheinlich von benutzerdefinierten Aggregatstatistiken ab primäre Datenquellen, wie z. B. die Volatilität in der jüngsten Preisentwicklung für viele Vermögenswerte, oder Text und Fotos aus Nachrichten über relevante Ereignisse. Da Rechenleistung und Bandbreite in einem DON relativ günstig sind, sind diese Statistiken – Sogar komplexe maschinelle Lernmodelle mit vielen Eingaben können wirtschaftlich verarbeitet werden, solange jeder Ausgabewert, der für einen blockchain bestimmt ist, ausreichend prägnant ist. Für rechenintensive Aufgaben, bei denen DON Teilnehmer möglicherweise unterschiedliche haben Ansichten zu komplexen Eingaben erfordern möglicherweise zusätzliche Kommunikationsrunden zwischen den DON-Teilnehmern, um vor der Berechnung des Ergebnisses einen Konsens über die Eingaben herzustellen. Solange der endgültige Wert vollständig durch die Eingaben bestimmt wird, kann jeder Teilnehmer, sobald ein Eingabekonsens hergestellt ist, einfach den Wert berechnen und ihn an den anderen weitergebenTeilen Sie den Teilnehmern ihre Teilsignatur mit oder senden Sie sie an einen Aggregator. 7.2 DON Vertrauensminimierung Wir stellen uns zwei Hauptmöglichkeiten vor, um das Vertrauen in Komponenten des DON zu minimieren: Failover-Clients und Minderheitsberichte. 7.2.1 Failover-Clients Gegnerische Modelle in der Literatur zu Kryptographie und verteilten Systemen typischerweise Betrachten Sie einen Gegner, der in der Lage ist, eine Teilmenge von Knoten zu beschädigen (d. h. zu kompromittieren). z. B. weniger als ein Drittel für viele BFT-Protokolle. Es wird jedoch häufig beobachtet, Wenn auf allen Knoten identische Software ausgeführt wird, könnte ein Angreifer dies tun, der einen schwerwiegenden Exploit identifiziert Im Prinzip gefährden sie alle Knoten mehr oder weniger gleichzeitig. Diese Einstellung ist häufig wird als Software-Monokultur bezeichnet [47]. Zur Lösung des Problems wurden verschiedene Vorschläge zur automatischen Diversifizierung von Software und Softwarekonfigurationen unterbreitet, z. B. [47, 113]. Wie in [47] erwähnt, Softwarevielfalt ist jedoch ein komplexes Thema und erfordert sorgfältige Abwägung. Software-Diversifizierung kann beispielsweise zu einer schlechteren Sicherheit führen als eine Monokultur, wenn dies der Fall wäre vergrößert die Angriffsfläche eines Systems und damit seine möglichen Angriffsvektoren um ein Vielfaches welche Sicherheitsvorteile es bietet. Wir glauben, dass Unterstützung für robuste Failover-Clients – d. h. Clients, zu denen Knoten gehören kann angesichts eines katastrophalen Ereignisses wechseln – ist eine besonders attraktive Form von Software-Diversifizierung. Failover-Clients erhöhen nicht die Anzahl potenzieller Vektoren Angriffsfläche, da sie nicht als Mainline-Software eingesetzt werden. Sie bieten klare Vorteile, jedoch als zweite Verteidigungslinie. Wir beabsichtigen, Failover-Clients in DONs zu unterstützen ein wichtiges Mittel, um ihre Sicherheitsabhängigkeit von einem einzigen Client zu verringern. Chainlink verfügt bereits über ein robustes System von Failover-Clients. Unser Ansatz beinhaltet die Pflege früherer, kampferprobter Client-Versionen. Heutzutage bieten beispielsweise Chainlink-Knoten mit Off-Chain Reporting (OCR) als primärem Client Unterstützung für das vorherige FluxMonitor-System von Chainlink, falls erforderlich. Seit einiger Zeit im Einsatz Gleichzeitig hat FluxMonitor Sicherheitsüberprüfungen und Feldtests durchlaufen. Es bietet das Gleiche Funktionalität wie OCR, allerdings zu höheren Kosten – Kosten, die nur bei Bedarf anfallen. 7.2.2 Minderheitenberichte Bei einer ausreichend großen Minderheitsgruppe Ominority – einem Bruchteil ehrlicher Knoten, die Fehlverhalten der Mehrheit beobachten – kann es für sie hilfreich sein, eine Minderheit zu generieren Bericht. Dies ist ein paralleler Bericht oder eine Flagge, die an einen abhängigen Vertrags-SC in der Kette weitergeleitet wird von Ominority. SC kann von diesem Flag gemäß seiner eigenen vertragsspezifischen Richtlinie Gebrauch machen. Beispielsweise kann bei einem Vertrag, bei dem Sicherheit wichtiger ist als Lebendigkeit oder Reaktionsfähigkeit, ein Minderheitsbericht dazu führen, dass der Vertrag zusätzliche Berichte anfordert von einem anderen DON oder lösen Sie einen Schutzschalter aus (siehe nächster Abschnitt).Berichte von Minderheiten können eine wichtige Rolle spielen, auch wenn die Mehrheit ehrlich ist. weil jedes Berichtsaggregationsschema, auch wenn es funktionale Signaturen verwendet, dies tun muss arbeiten auf Schwellenwertbasis, um die Widerstandsfähigkeit gegen oracle oder Datenfehler sicherzustellen. In Mit anderen Worten: Es muss möglich sein, auf der Grundlage der Eingaben von einen gültigen Bericht zu erstellen kS < nS oracles, für einen bestimmten Schwellenwert kS. Dies bedeutet, dass ein beschädigter DON welche hat Spielraum bei der Manipulation von Berichtswerten durch Auswahl der bevorzugten kS-Werte unter den nS wurde in V durch den gesamten Satz von oracles gemeldet, auch wenn alle Quellen ehrlich sind. Nehmen wir zum Beispiel an, dass nS = 10 und kS = 7 in einem System ist, das ein Funktional verwendet Signatur zur Authentifizierung der Berechnung des Medians über V für den USD-Preis der ETH. Angenommen, fünf Quellen melden einen Preis von \(500, while the other five report \)1000. Durch Medianisierung der niedrigsten 7 Berichte kann DON dann einen gültigen Wert v = 500 $ ausgeben. und durch Medianisierung des Höchstwerts kann v = 1000 $ ausgegeben werden. Durch die Erweiterung des DON-Protokolls, sodass alle Knoten wissen, welche Daten vorhanden waren Welche Daten verfügbar sind und welche Daten zur Erstellung eines Berichts verwendet wurden, konnten die Knoten erkennen und kennzeichnen statistisch signifikante Tendenzen, eine Reihe von Berichten einer anderen vorzuziehen und zu produzieren ein Minderheitsbericht als Ergebnis. 7.3 Leitplanken Unser Vertrauensmodell für DONs behandelt MAINCHAIN als eine höhere Sicherheit und höhere Privilegien System als DONs. (Obwohl dieses Vertrauensmodell möglicherweise nicht immer zutrifft, ist es einfacher um den resultierenden Mechanismus an Situationen anzupassen, in denen DON die höhere Sicherheit bietet Plattform als umgekehrt.) Eine natürliche Strategie zur Vertrauensminimierung beinhaltet daher die Implementierung von Überwachungs- und Ausfallsicherheitsmechanismen in smart contracts – entweder in einem MAINCHAIN-Frontend für einen DON oder direkt in einem abhängigen Vertrag SC. Wir bezeichnen diese Mechanismen als Leitplanken und nennen hier einige der wichtigsten: • Leistungsschalter: SC kann Zustandsaktualisierungen in Abhängigkeit von den Merkmalen der Zustandsaktualisierungen selbst pausieren oder stoppen (z. B. große Varianz über die Sequenz hinweg). Berichte) oder basierend auf anderen Eingaben. Beispielsweise könnte ein Schutzschalter auslösen Fälle, in denen oracle-Berichte im Laufe der Zeit unplausibel variieren. Ein Schutzschalter könnte sein auch durch eine Minderheitsmeldung ausgelöst werden. Somit können Leistungsschalter DONs verhindern davon abzuhalten, grob fehlerhafte Berichte zu erstellen. Leistungsschalter können Zeit für die Überlegung zusätzlicher Eingriffe schaffen oder trainiert. Ein solcher Eingriff sind Notluken. • Notausstiege: Unter widrigen Umständen, die von einer Gruppe von Verwaltern, Gemeindeinhabern oder anderen Treuhändergremien festgestellt werden, kann ein Vertrag in Kraft treten eine Notfalleinrichtung, manchmal auch Notluke genannt [163]. Eine Notluke bewirkt, dass SC auf irgendeine Weise heruntergefahren wird und/oder ausstehend und möglicherweise beendet wird zukünftige Transaktionen. Es kann beispielsweise verwahrte Gelder an Benutzer [17] zurückgeben.kann Vertragsbedingungen kündigen [162] oder ausstehende und/oder zukünftige Transaktionen stornieren [173]. Notluken können in jeder Art von Vertrag eingesetzt werden, nicht nur eine, die auf einem DON basiert, aber als potenzieller Puffer dagegen von Interesse ist DON Fehlverhalten. • Failover: In Systemen, in denen SC für wesentliche Dienste auf DON angewiesen ist, ist es für SC möglich, Failover-Mechanismen bereitzustellen, die eine gleichmäßige Dienstkontinuität gewährleisten im Falle von DON Versagen oder Fehlverhalten. Beispielsweise im TEF (Abschnitt 6): Der Ankervertrag SCa kann zwei Schnittstellen bereitstellen, sowohl in der Kette als auch in der Kette Für bestimmte kritische Vorgänge werden Off-Chain-Ausführungsschnittstellen unterstützt (z. B. Auszahlung) oder bei gewöhnlichen Transaktionen mit einer angemessenen Verzögerung, um ein vorzeitiges Ausführen von DON-Transaktionen zu verhindern. In Fällen, in denen Datenquellen Daten signieren, könnten Benutzer dies tun Legen Sie auch Berichte an SCa vor, wenn der DON dies nicht tut. Betrugsbeweise, wie sie für verschiedene Formen optimistischer rollup vorgeschlagen werden (siehe Abschnitt 6.3), sind im Geschmack ähnlich und ergänzen die Mechanismen, die wir oben aufgezählt haben. Sie bieten auch eine Form der On-Chain-Überwachung und des Schutzes vor möglichen Ausfällen in Off-Chain-Systemkomponenten. 7.4 Vertrauensminimierte Governance Wie alle dezentralen Systeme erfordert das Chainlink-Netzwerk Governance-Mechanismen um Parameter im Laufe der Zeit anzupassen, auf Notfälle zu reagieren und ihre Entwicklung zu steuern. Einige dieser Mechanismen befinden sich derzeit auf MAINCHAIN und werden dies möglicherweise auch weiterhin tun Tun Sie dies auch mit der Bereitstellung von DONs. Ein Beispiel ist der Zahlungsmechanismus für oracle-Knotenanbieter (DON-Knoten). DON Front-End-Verträge auf MAINCHAIN enthalten zusätzliche Mechanismen, wie z. B. Leitplanken, die periodisch beansprucht werden können Modifikation. Wir sehen zwei Klassen von Governance-Mechanismen vor: evolutionäre und Notfallmechanismen. Evolutionäre Governance: Es gibt viele Änderungen am Chainlink-Ökosystem sodass deren Umsetzung nicht dringlich ist: Leistungsverbesserungen, Funktionserweiterungen, (nicht dringende) Sicherheitsupgrades usw. Da Chainlink immer mehr Teilnehmer an seiner Governance beteiligt, erwarten wir viele oder Die meisten dieser Änderungen müssen von der Gemeinschaft eines bestimmten DON, der davon betroffen ist, ratifiziert werden Änderungen. Wir glauben, dass dies in der Zwischenzeit und möglicherweise letztendlich als paralleler Mechanismus der Fall sein wird dass die Vorstellung des zeitlich geringsten Privilegs ein nützliches Mittel zur Umsetzung evolutionärer Governance sein kann. Die Idee besteht ganz einfach darin, dass Änderungen schrittweise eingeführt werden, um sicherzustellen, dass dies gewährleistet ist der Community die Möglichkeit, darauf zu reagieren. Zum Beispiel die Migration auf ein neues Der MAINCHAIN-Vertrag kann eingeschränkt werden, sodass der neue Vertrag bereitgestellt werden muss mindestens dreißig Tage vor der Aktivierung.Notfall-Governance: Ausnutzbare oder ausgenutzte Schwachstellen in MAINCHAIN Verträge oder andere Formen der Lebendigkeit oder Sicherheitsmängel können ein sofortiges Eingreifen erfordern, um katastrophale Folgen zu verhindern. Unsere Absicht ist es, ein Multisig zu unterstützen Interventionsmechanismus, der zum Schutz vor Fehlverhalten einer Organisation Die Unterzeichner werden auf verschiedene Organisationen verteilt sein. Sicherstellung einer konsistenten Verfügbarkeit von Unterzeichnern und rechtzeitiger Zugriff auf geeignete Befehlsketten zur Genehmigung von Notfällen Änderungen erfordern eindeutig eine sorgfältige operative Planung und regelmäßige Überprüfung. Diese Die Herausforderungen ähneln denen beim Testen anderer Cybersicherheits-Vorfallreaktionen Fähigkeiten [134], mit einem ähnlichen Bedarf, häufige Probleme wie die Dekrementierung der Wachsamkeit zu bekämpfen [223]. Die Governance von DONs unterscheidet sich von der vieler dezentraler Systeme in ihrem potenzieller Grad der Heterogenität. Jeder DON kann unterschiedliche Datenquellen, ausführbare Dateien, Service-Level-Anforderungen wie Betriebszeit und Benutzer haben. Das Netzwerk Chainlink Governance-Mechanismen müssen flexibel genug sein, um solche Unterschiede zu berücksichtigen operative Ziele und Parameter. Wir prüfen aktiv Designideen und planen dies in Zukunft Forschungsergebnisse zu diesem Thema veröffentlichen. 7.5 Public-Key-Infrastruktur Mit der fortschreitenden Dezentralisierung wird die Notwendigkeit einer robusten Identifizierung von entstehen Netzwerkteilnehmer, einschließlich DON Knoten. Insbesondere Chainlink erfordert eine starke Public-Key-Infrastruktur (PKI). Eine PKI ist ein System, das Schlüssel an Identitäten bindet. Für Beispielsweise liegt eine PKI dem System sicherer Verbindungen (TLS) des Internets zugrunde: Wann Sie stellen über HTTPS (z. B. https://www.chainlinklabs.com) eine Verbindung zu einer Website her und a Wenn in Ihrem Browser ein Schloss erscheint, bedeutet dies, dass Sie über den öffentlichen Schlüssel des Domaininhabers verfügen durch eine Autorität an diesen Eigentümer gebunden wurden – insbesondere durch eine digitale Signatur in ein sogenanntes Zertifikat. Ein hierarchisches System von Zertifizierungsstellen (CAs), deren Root-Zertifizierungen der obersten Ebene in gängigen Browsern fest verankert sind, trägt dazu bei, dass Zertifikate gewährleistet sind werden nur an die rechtmäßigen Inhaber von Domains ausgegeben. Wir gehen davon aus, dass Chainlink irgendwann dezentrale Namensdienste nutzen wird, zunächst der Ethereum Name Service (ENS) [22], als Grundlage für unsere PKI. Als Der Name lässt vermuten, dass ENS eine Analogie zu DNS ist, dem Domain Name System, das Karten abbildet (für Menschen lesbare) Domainnamen in IP-Adressen im Internet umwandeln. ENS ordnet jedoch stattdessen menschenlesbare Ethereum-Namen blockchain-Adressen zu. Weil ENS arbeitet auf dem Ethereum blockchain, es sei denn, der Schlüssel wird kompromittiert oder manipuliert Der Namespace ist im Prinzip genauso schwierig wie die Manipulation des Vertrags, der ihn verwaltet und/oder der zugrunde liegende blockchain. (Im Gegensatz dazu war DNS in der Vergangenheit anfällig zu Spoofing, Hijacking und anderen Angriffen.) Wir haben data.eth bei ENS im Hauptnetz Ethereum registriert und beabsichtigen, dies zu tun Richten Sie es als Root-Namespace ein, unter dem die Identitäten der Datendienste oracle und andere Chainlink Netzwerkeinheiten befinden sich. Domänen in ENS sind hierarchisch, was bedeutet, dass jede Domäne Referenzen enthalten kann zu anderen Namen darunter. Subdomains in ENS können zur Organisation und Organisation dienenVertrauen delegieren. Die Hauptaufgabe von data.eth wird darin bestehen, als On-Chain-Verzeichnisdienst für zu dienen Datenfeeds. Traditionell haben Entwickler und Benutzer von oracles Off-Chain-Quellen verwendet (z. B. Websites wie docs.chain.link oder data.chain.link oder soziale Netzwerke wie Twitter), um oracle Daten-Feed-Adressen (z. B. den ETH-USD-Preis) zu veröffentlichen und zu erhalten Futter). Mit einem äußerst vertrauenswürdigen Root-Namespace wie data.eth ist es stattdessen möglich, eine Zuordnung von eth-usd.data.eth beispielsweise zur Adresse smart contract einzurichten eines On-Chain-Netzwerkaggregators oracle für den ETH-USD-Preis-Feed. Das würde Erstellen Sie einen sicheren Pfad, auf dem sich jeder auf blockchain als Quelle der Wahrheit beziehen kann dieser Daten-Feed dieses Preis-/Namenpaares (ETH-USD). Folglich ist eine solche Verwendung von ENS realisiert zwei Vorteile, die in Off-Chain-Datenquellen nicht verfügbar sind: • Hohe Sicherheit: Alle Änderungen und Aktualisierungen der Domain werden unveränderlich aufgezeichnet und kryptografisch gesichert, im Gegensatz zu Textadressen auf einer Website, die Genießen Sie keine dieser beiden Sicherheitseigenschaften. • Automatisierte On-Chain-Weitergabe: Aktualisierungen der zugrunde liegenden Adresse des smart contract eines Datenfeeds können Benachrichtigungen auslösen, die an abhängige Smart weitergegeben werden Verträge und kann beispielsweise abhängige Verträge automatisch mit aktualisieren die neuen Adressen.13 Namespaces wie ENS validieren jedoch nicht automatisch den legitimen Besitz der behaupteten Namen. Also zum Beispiel, wenn der Namensraum den Eintrag enthält ⟨„Acme Oracle Node Co.“, Adresse⟩, Dann erhält ein Benutzer die Gewissheit, dass die Adresse dem Antragsteller mit dem Namen Acme gehört Oracle Node Co. Ohne zusätzliche Mechanismen rund um die Namespace-Verwaltung, Sie erhält jedoch keine Gewissheit darüber, dass der Name rechtmäßig einer juristischen Person gehört im wahrsten Sinne des Wortes Acme Oracle Node Co. genannt. Unser Ansatz zur Validierung von Namen, d. h. zur Sicherstellung ihres Besitzes durch entsprechende, legitime Entitäten in der realen Welt, basiert auf mehreren Komponenten. Heute, Chainlink Labs Fungiert effektiv als Zertifizierungsstelle für das Netzwerk Chainlink. Während Chainlink Labs weitergeführt werden Um Namen zu validieren, wird sich unsere PKI auf zwei Arten zu einem dezentraleren Modell entwickeln: • Web-of-Trust-Modell: Das dezentrale Gegenstück einer hierarchischen PKI wird oft als Web-of-Trust bezeichnet.14 Varianten wurden seit den 1990er Jahren vorgeschlagen, B. [98], und eine Reihe von Forschern haben beobachtet, dass blockchains die Verwendung der Idee, z. B. [227], erleichtern können, indem sie Zertifikate global konsistent aufzeichnen Hauptbuch. Wir untersuchen Varianten dieses Modells, um die Identität von Entitäten zu validieren im Chainlink-Netzwerk auf dezentralere Weise. 13Ein abhängiger Vertrag kann optional eine vorab festgelegte Verzögerung enthalten, um eine manuelle Überprüfung zu ermöglichen und Eingriffe von abhängigen Vertragsverwaltern. 14Ein von Phil Zimmermann geprägter Begriff für PGP [238].• Verknüpfung mit Validierungsdaten: Heutzutage ist eine beträchtliche Menge an oracle-Knotenleistungsdaten in der Kette sichtbar und daher archiviert an Knotenadressen gebunden. Solche Daten können als Bereicherung einer Identität in der PKI angesehen werden, indem sie historische Beweise für ihre (zuverlässige) Teilnahme am Netzwerk liefern. Zusätzlich Werkzeuge für dezentrale Identität basierend auf DECO- und Town Crier [160]-Aktivierungsknoten um aus realen Daten abgeleitete Anmeldeinformationen zu sammeln. Nur ein Beispiel: a Der Knotenbetreiber kann seiner PKI-Identität einen Berechtigungsnachweis hinzufügen, der den Besitz nachweist einer Bewertung von Dun und Bradstreet. Diese ergänzenden Formen der Validierung können Ergänzung staking bei der Gewährleistung der Sicherheit des Netzwerks. Ein oracle-Knoten mit einer etablierten realen Identität kann als beteiligt angesehen werden in einem System, das sich aus seinem Ruf ergibt. (Siehe Abschnitt 4.3 und Abschnitt 9.6.3.) Eine letzte Voraussetzung für die PKI Chainlink ist sicheres Bootstrapping, also sicher Veröffentlichung des Root-Namens für das Netzwerk Chainlink, derzeit data.eth (analog). zur Festverdrahtung von Top-Level-Domains in Browsern). Mit anderen Worten: Wie geht es Chainlink Benutzern? Stellen Sie fest, dass data.eth tatsächlich die Top-Level-Domain ist, die mit Chainlink verknüpft ist. Projekt? Die Lösung für dieses Problem für das Netzwerk Chainlink ist vielschichtig und kann Folgendes umfassen: • Hinzufügen eines TXT-Eintrags [224] zu unserem Domain-Eintrag für chain.link, der Folgendes angibt data.eth als Stammdomäne für das Ökosystem Chainlink. (Chainlink nutzt somit implizit die PKI für Internetdomänen, um ihre Root-ENS-Domäne zu validieren.) • Verlinkung zu data.eth von der bestehenden Website von Chainlink, z. B. von https://docs.chain.link. (Eine weitere implizite Verwendung der PKI für Internetdomänen.) • Bekanntmachung der Nutzung von data.eth durch verschiedene Dokumente, darunter dieses Whitepaper. • Öffentliches Posten von data.eth auf unseren Social-Media-Kanälen wie Twitter und der Chainlink Blog [18]. • Unterbringung einer großen Menge an LINK unter der Kontrolle derselben Registrantenadresse als data.eth.

DON Überlegungen zur Bereitstellung

Obwohl dies nicht Teil unseres Kerndesigns ist, gibt es einige wichtige technische Überlegungen in der Verwirklichung von DONs, die hier behandelt werden sollten.

8.1 Rollout-Ansatz In diesem Dokument wird eine ehrgeizige Vision einer erweiterten Chainlink-Funktionalität dargelegt Die Verwirklichung erfordert Lösungen für viele Herausforderungen auf dem Weg. Dieses Whitepaper identifiziert einige Herausforderungen, aber es werden mit Sicherheit auch unvorhergesehene auftreten. Wir planen, Elemente dieser Vision schrittweise im Laufe eines Jahres umzusetzen längere Zeitspanne. Wir gehen davon aus, dass DONs zunächst mit starten werden Unterstützung für bestimmte vorgefertigte Komponenten, die gemeinsam von Teams innerhalb der entwickelt wurden Chainlink Gemeinschaft. Die Absicht besteht darin, breitere Verwendungsmöglichkeiten von DONs zu schaffen, z. B. die Fähigkeit, Starten Sie beliebige ausführbare Dateien. Die Unterstützung wird zu einem späteren Zeitpunkt verfügbar sein. Ein Grund für diese Vorsicht besteht darin, dass die Zusammensetzung von smart contracts komplexe, unbeabsichtigte und gefährliche Nebenwirkungen haben kann, wie es in jüngster Zeit bei Angriffen auf Basis von Flash-Krediten der Fall war zum Beispiel gezeigt [127, 189]. Ebenso die Zusammensetzung von smart contracts, Adaptern und Ausführbare Dateien erfordern äußerste Sorgfalt. In unserer ersten Bereitstellung von DONs planen wir, nur einen vorgefertigten Satz ausführbarer Vorlagen und Adapter einzubeziehen. Dies wird eine Untersuchung der kompositorischen Sicherheit ermöglichen dieser Funktionalitäten mithilfe formaler Methoden [46, 170] und anderer Ansätze. Das wird es Vereinfachen Sie auch die Preisgestaltung: Die Preisgestaltung für Funktionalitäten kann von DON-Knoten auf Basis einer einzelnen Funktionalität festgelegt werden, statt durch eine allgemeine Messung, wie es bei diesem Ansatz der Fall ist in, z. B. [156]. Wir erwarten auch, dass sich die Chainlink-Community an der Erstellung beteiligt von zusätzlichen Vorlagen, die verschiedene Adapter und ausführbare Dateien zu immer mehr kombinieren nützliche dezentrale Dienste, die von Hunderten, wenn nicht Tausenden von Einzelpersonen betrieben werden können DONs. Darüber hinaus kann dieser Ansatz dazu beitragen, ein Aufblähen des Staates zu verhindern, d. h. die Notwendigkeit von DON Knoten, um eine nicht bearbeitbare Zustandsmenge im Arbeitsspeicher zu behalten. Dieses Problem ist entstehen bereits in erlaubnislosen blockchains, motivierenden Ansätzen wie „staatenlos“. Kunden“ (siehe z. B. [206]). In Systemen mit höherem Durchsatz kann es akuter und motivierender sein ein Ansatz, bei dem ein DON nur ausführbare Dateien bereitstellt, die für die Zustandsgröße optimiert sind. Da sich DONs weiterentwickeln und ausgereift sind und robuste Leitplanken (siehe Abschnitt 7), kryptoökonomische und reputationsbasierte Sicherheitsmechanismen (siehe Abschnitt 9) sowie andere Funktionen umfassen, die DON-Benutzern ein hohes Maß an Sicherheit bieten, werden wir Erwarten Sie außerdem die Entwicklung eines Frameworks und von Tools, um eine breitere Einführung und Nutzung zu erleichtern DONs von der Community. Im Idealfall ermöglichen diese Tools eine Sammlung von Knotenoperatoren als oracle-Netzwerk zusammenzukommen und ihre eigenen DONs ohne Erlaubnis zu starten oder im Selbstbedienungsmodus, was bedeutet, dass sie dies einseitig tun können. 8.2 Dynamische DON-Mitgliedschaft Die Gruppe der Knoten, auf denen ein bestimmter DON ausgeführt wird, kann sich im Laufe der Zeit ändern. Es gibt zwei Ansätze zum Schlüsselmanagement für skL bei dynamischer Mitgliedschaft in O. Die erste besteht darin, die von den Knoten gehaltenen skL-Anteile bei Änderungen der Mitgliedschaft zu aktualisieren. während pkL unverändert bleibt. Dieser in [41, 161, 198] untersuchte Ansatz hat seine Vorzüge nicht zu verlangen, dass vertrauende Parteien pkL aktualisieren.Die klassische Technik des Teilens erneut teilen, eingeführt in [122], bietet eine einfache Möglichkeit und effiziente Möglichkeit, solche Share-Updates zu realisieren. Es ermöglicht die Übertragung eines Geheimnisses zwischen einem Satz von Knoten O(1) und einem zweiten, der möglicherweise einen Knoten O(2) schneidet. Dabei Ansatz, jeder Knoten O(1) ich führt eine (k(2), n(2)) geheime Weitergabe seines geheimen Anteils durch Knoten in O(2) für n(2) = |O(2)| und gewünschter (möglicherweise neuer) Schwellenwert k(2). Verschiedene verifizierbare Secret-Sharing-Systeme (VSS) [108] können Sicherheit vor einem Angreifer bieten korrumpiert aktiv Knoten, d. h. führt bösartiges Verhalten in das Protokoll ein. Die Techniken in [161] zielen darauf ab, die Kommunikationskomplexität zu reduzieren und bereitzustellen Widerstandsfähigkeit gegenüber Fehlern in kryptografischen Härteannahmen. Ein zweiter Ansatz besteht darin, den Hauptbuchschlüssel pkL zu aktualisieren. Dies hat den Vorteil der Vorwärtsbewegung Sicherheit: Eine Kompromittierung alter Aktien von PKL (d. h. ehemaliger Ausschussknoten) wäre nicht möglich Dies kann zu einer Kompromittierung des aktuellen Schlüssels führen. Aktualisierungen von pkL bringen jedoch zwei Nachteile mit sich: (1) Unter pkL verschlüsselte Daten müssen während einer Schlüsselaktualisierung erneut verschlüsselt werden und (2) Wichtige Aktualisierungen müssen an vertrauende Parteien weitergegeben werden. Wir beabsichtigen, beide Ansätze sowie Hybridisierungen der beiden zu untersuchen. 8.3 DON Verantwortlichkeit Wie bestehende Chainlink oracle-Netzwerke werden DONs Mechanismen zur Verantwortlichkeit enthalten, d. h. zur Aufzeichnung, Überwachung und Durchsetzung des korrekten Knotenverhaltens. DONs werden haben viel größere Datenkapazität als viele bestehende erlaubnislose blockchains, insbesondere angesichts ihrer Fähigkeit, eine Verbindung zu einem externen dezentralen Speicher herzustellen. Folglich können sie den Leistungsverlauf der Knoten detailliert aufzeichnen und so Folgendes berücksichtigen: Feinkörnigere Rechenschaftsmechanismen. Zum Beispiel die Off-Chain-Berechnung von Bei Vermögenspreisen kann es sich um Eingaben handeln, die verworfen werden, bevor ein mittleres Ergebnis übermittelt wird Kette. In einem DON könnten diese Zwischenergebnisse festgehalten werden. Fehlverhalten oder Leistungseinbußen einzelner Knoten in einem DON können so behoben oder bestraft werden die DON auf feinkörnige Weise. Darüber hinaus haben wir Ansätze zum Bauen besprochen Leitplanken in Abschnitt 7.3, die sich mit den vertragsspezifischen Auswirkungen systemischer Ausfälle befassen. Es ist jedoch auch wichtig, über ausfallsichere Mechanismen für DONs selbst zu verfügen, d. h. Schutz vor systemischen, potenziell katastrophalen DON Ausfällen, insbesondere Forking-/Äquivokations- und Service-Level-Agreement-(SLA)-Fehler, wie wir jetzt erklären. Gabelung / Mehrdeutigkeit: Bei ausreichend vielen fehlerhaften Knoten kann ein DON forken oder zweideutig sein, wodurch zwei unterschiedliche, inkonsistente Blöcke oder Blockfolgen in L entstehen. Da ein DON den Inhalt von L jedoch digital signiert, ist es möglich, a zu nutzen Hauptkette MAINCHAIN, um Zweideutigkeiten zu verhindern und/oder zu bestrafen. Der DON kann den Status von L in einem Prüfvertrag auf MAINCHAIN ​​regelmäßig überprüfen. Wenn sein zukünftiger Zustand von einem Checkpoint-Zustand abweicht, kann ein Benutzer/Prüfer einen Nachweis vorlegen dieses Fehlverhaltens auf den Prüfungsvertrag zurückzuführen. Ein solcher Nachweis kann zur Generierung einer Warnung verwendet werden oder DON-Knoten durch Kürzungen im Vertrag bestrafen. Dieser letztere Ansatz führt ein ein Anreizdesignproblem, das dem für bestimmte oracle-Feeds ähnelt und darauf aufbauen kann unsere in Abschnitt 9 beschriebene Arbeit.Durchsetzung von Service-Level-Agreements: Während DONs nicht unbedingt dazu gedacht sind Da sie auf unbestimmte Zeit laufen, ist es wichtig, dass sie sich an Service Level Agreements (SLAs) halten. mit ihren Benutzern. Eine grundlegende SLA-Durchsetzung ist in einer Hauptkette möglich. Zum Beispiel, DON-Knoten könnten sich verpflichten, den DON bis zu einem bestimmten Datum aufrechtzuerhalten oder die Beendigung des Dienstes im Voraus anzukündigen (z. B. mit einer Frist von drei Monaten). Ein Vertrag über MAINCHAIN kann eine grundlegende kryptoökonomische SLA-Durchsetzung bieten. Beispielsweise kann der SLA-Vertrag die eingezahlten DON-Gelder drastisch reduzieren, wenn Kontrollpunkte vorhanden sind nicht in den erforderlichen Abständen bereitgestellt. Ein Benutzer kann Geld einzahlen und den DON anfechten. um zu beweisen, dass ein Prüfpunkt eine Folge gültiger Blöcke korrekt darstellt (in gewisser Weise). analog zu z.B. [141]). Natürlich ist die Blockproduktion nicht gleichbedeutend mit einer Transaktion Verarbeitung, der SLA-Vertrag kann aber auch deren Durchsetzung dienen. Zum Beispiel in Die Legacy-kompatible Version von FSS, bei der Transaktionen aus dem Mempool abgerufen werden (siehe Abschnitt 5.2), Transaktionen schließlich abgebaut und in die Kette gestellt werden. Ein Benutzer kann DON ein Fehlverhalten nachweisen, indem er den SLA-Vertrag mit einer Transaktion ausstattet, die wurde abgebaut, aber nicht von DON zur Verarbeitung durch den Zielvertrag übermittelt innerhalb der angemessenen Zeitspanne.15 Es ist auch möglich, die Existenz feinkörnigerer SLA nachzuweisen und diese zu bestrafen Ausfälle, einschließlich Fehler bei der Berechnung mithilfe ausführbarer Dateien (z. B. über die Mechanismen). zum Nachweis korrekter Off-Chain-Statustransaktionen (siehe Abschnitt 6.3) oder zum Scheitern der Ausführung Ausführbare Dateien basierend auf Initiatoren, die auf einem DON sichtbar sind, Fehler beim Weiterleiten von Daten auf dem DON MAINCHAIN rechtzeitig usw.

Wirtschaftswissenschaften und Kryptoökonomie

Damit das Chainlink-Netzwerk innerhalb eines dezentralen Vertrauensmodells eine starke Sicherheit erreichen kann, Es ist wichtig, dass die Knoten gemeinsam ein korrektes Verhalten zeigen, das heißt, dass sie haften meistens genau nach DON Protokollen. In diesem Abschnitt diskutieren wir Ansätze dazu beizutragen, ein solches Verhalten durch wirtschaftliche Anreize, auch bekannt als Kryptoökonomie, durchzusetzen Anreize. Diese Anreize lassen sich in zwei Kategorien einteilen: explizite und implizite, realisierte jeweils über staking und zukünftige Gebührenmöglichkeit (FFO). Einsatz: Das Abstecken in Chainlink, wie auch in anderen blockchain-Systemen, beinhaltet Netzwerkteilnehmer, d. h. oracle-Knoten, die gesperrte Gelder in Form von LINK tokens einzahlen. Diese Mittel, die wir auch als Anteile oder explizite Anteile bezeichnen, sind ein expliziter Anreiz. Sie können bei Knotenausfall oder Fehlverhalten verfallen. Im Kontext blockchain Dieser Vorgang wird oft als Slashing bezeichnet. Das Abstecken durch oracle-Knoten in Chainlink unterscheidet sich jedoch grundlegend von staking von validators in erlaubnislosen blockchains. Validatoren können sich schlecht verhalten, indem sie Transaktionen zweideutig machen oder widersprüchlich anordnen. Das zugrunde liegende Konsensprotokoll in a 15Da Benutzer Transaktionen im Mempool ersetzen können, muss darauf geachtet werden, dass eine korrekte Übereinstimmung zwischen den abgebauten und DON-übermittelten Transaktionen gewährleistet ist.Der erlaubnislose blockchain verwendet jedoch strenge Blockvalidierungsregeln und kryptografische Grundelemente, um zu verhindern, dass validators ungültige Blöcke generieren. Im Gegensatz dazu Programmgesteuerte Schutzmaßnahmen können nicht verhindern, dass ein betrügerisches oracle-Netzwerk generiert wird ungültige Berichte. Der Grund ist ein wesentlicher Unterschied zwischen den beiden Systemtypen: Die Transaktionsvalidierung in blockchains ist eine Eigenschaft der internen Konsistenz, während die Korrektheit von oracle-Berichten über einen blockchain ist eine Eigenschaft externer, d. h. Off-Chain-Daten. Wir haben einen vorläufigen staking-Mechanismus für das Chainlink-Netzwerk entwickelt auf einem interaktiven Protokoll zwischen oracle-Knoten, das externe Daten nutzen kann. Dies Mechanismus schafft finanzielle Anreize für korrektes Verhalten durch explizite Belohnungen und Strafen (Schneiden). Da der Mechanismus wirtschaftlich ist, soll er Knoten verhindern Korruption durch einen Gegner, der finanzielle Ressourcen nutzt, um Knoten zu korrumpieren Bestechung. (Ein solcher Gegner ist sehr allgemein und erstreckt sich beispielsweise auf Knoten, mit denen er kooperiert Wert aus ihrem kollektiven Fehlverhalten ziehen.) Der von uns entworfene Mechanismus Chainlink staking ist leistungsstark und neuartig Merkmale.16 Das wichtigste Merkmal dieser Art ist der superlineare staking Einfluss (insbesondere quadratisch). Ein Gegner muss über Ressourcen verfügen, die deutlich über den von den Knoten eingezahlten Geldern liegen um den Mechanismus zu untergraben. Unser staking-Mechanismus bietet zusätzlich Schutz vor einem stärkeren Gegner als bisher in ähnlichen Systemen berücksichtigt, nämlich ein Gegner, der Bestechungsgelder erzeugen kann, die das zukünftige Verhalten von Knoten beeinflussen. Darüber hinaus besprechen wir, wie Chainlink Tools wie DECO zur Stärkung unseres staking beitragen können. Mechanismus, indem es eine korrekte Entscheidung im Falle eines fehlerhaften Knotenverhaltens erleichtert. Zukünftige Gebührenmöglichkeit (FFO): Erlaubnislose blockchains – beider PoW und PoS-Vielfalt – verlassen sich heute entscheidend auf das, was wir implizite Anreize nennen. Das sind wirtschaftliche Anreize für ehrliches Verhalten, die nicht aus expliziten Belohnungen resultieren, sondern aus der Plattformbeteiligung selbst. Beispielsweise besteht für die Bitcoin-Miner-Community ein Anreiz, keinen 51-Prozent-Angriff zu starten, da das Risiko besteht, dass das Vertrauen in sie untergraben wird Bitcoin, was seinen Wert mindert und folglich den Wert ihres Kollektivs untergräbt Kapitalinvestitionen in die Bergbauinfrastruktur [150]. Das Chainlink-Netzwerk profitiert von einem ähnlichen impliziten Anreiz, auf den wir uns beziehen als zukünftige Gebührenmöglichkeit (FFO). Oracle-Knoten mit starker Leistungshistorie oder Reputationen ziehen Gebühren von den Nutzern nach sich. Fehlverhalten eines oracle-Knotens gefährdet die Zukunft Gebührenzahlungen und bestraft den Knoten somit mit Opportunitätskosten in Bezug auf das Potenzial Einnahmen, die durch die Teilnahme am Netzwerk erzielt werden. Analog zum expliziten Einsatz FFO kann als eine Form des impliziten Einsatzes betrachtet werden, als Anreiz für ehrliches Verhalten ergibt sich aus dem gemeinsamen Vorteil, das Vertrauen in die Plattform aufrechtzuerhalten, auf der Das Geschäft der Knotenbetreiber hängt davon ab, d. h. von der positiven Leistung und dem Ruf des Knotenbetreibers Netzwerk. Dieser Anreiz ist dem Netzwerk Chainlink inhärent, kommt aber nicht explizit zum Ausdruck Protokolle. In Bitcoin wird der Wert der Bergbaubetriebe wie oben erwähnt aufrechterhalten 16Der hier beschriebene staking-Mechanismus zielt derzeit nur darauf ab, die Zustellung korrekter Berichte zu erzwingen von oracle Netzwerken. Wir gehen davon aus, dass wir es in zukünftigen Arbeiten erweitern werden, um die korrekte Ausführung der vielen sicherzustellen weitere Funktionalitäten, die DONs bieten.kann in ähnlicher Weise als eine Form impliziter Beteiligung angesehen werden. Wir betonen, dass FFO bereits in Chainlink existiert und zur Sicherung des Netzwerks beiträgt heute. Unser Hauptbeitrag zur Weiterentwicklung von Chainlink wird ein prinzipieller, empirisch fundierter Ansatz zur Bewertung impliziter Anreize wie FFO durch sein was wir das Implicit-Incentive Framework (IIF) nennen. Zum Schätzen von Mengen wie z Zukünftige Gebührenmöglichkeiten für Knotenpunkte werden vom IIF kontinuierlich auf das umfassende Angebot zurückgegriffen Leistungs- und Zahlungsdaten, die vom Netzwerk Chainlink gesammelt werden. Solche Schätzungen wird eine IIF-basierte Parametrisierung von staking-Systemen ermöglichen, die Knotenanreize widerspiegelt mit größerer Genauigkeit als aktuelle heuristische und/oder statische Modelle. Zusammenfassend also die beiden wichtigsten wirtschaftlichen Anreize für den richtigen oracle-Knoten Das Verhalten im sich entwickelnden Chainlink-Netzwerk wird sein: • Staking (hinterlegter Einsatz) o Expliziter Anreiz • Zukünftige Gebührenmöglichkeit (FFO) o Impliziter Anreiz Diese beiden Anreizformen ergänzen sich. Oracle-Knoten können gleichzeitig Nehmen Sie am Protokoll Chainlink staking teil und profitieren Sie von einer kontinuierlichen Einnahmequelle Benutzer und profitieren gemeinsam von ihrem anhaltend guten Verhalten. Also beide Anreize Tragen Sie zur kryptoökonomischen Sicherheit bei, die ein oracle-Netzwerk bietet. Darüber hinaus Die beiden Anreize können sich verstärken und/oder gegeneinander abgewogen werden. Zum Beispiel, Ein neuer oracle-Betreiber ohne Leistungshistorie und Einnahmequelle kann a einsetzen eine große Menge an LINKs als Garant für ehrliches Verhalten und locken so Nutzer an und Gebühren. Umgekehrt ist ein etablierter oracle-Operator mit einer langen, relativ fehlerfreien Zeit Performance History kann von einer großen Nutzerbasis erhebliche Gebühren verlangen und sich somit darauf verlassen stärker auf den FFO als eine Form des impliziten Anreizes. Im Allgemeinen zielt der hier betrachtete Ansatz auf eine bestimmte Menge an oracle-Netzwerken ab Ressource, um größtmögliche wirtschaftliche Anreize in Chainlink für rational zu schaffen Agenten – d. h. Knoten, die ihren finanziellen Nutzen maximieren – müssen sich ehrlich verhalten. Setzen Sie einen anderen Das Ziel besteht darin, die finanziellen Ressourcen zu maximieren, die ein Gegner für einen Angriff benötigt das Netzwerk erfolgreich. Indem Sie ein staking-Protokoll mathematisch gut formulieren Ziel ist es, die Stärke der definierten wirtschaftlichen Sicherheit zu messen und auch den IIF zu verwenden Chainlinks Anreize so genau wie möglich. Die Ersteller von Vertrauensverträgen werden es tun Dann können Sie mit großer Sicherheit feststellen, ob ein oracle-Netzwerk zusammentrifft ihr erforderliches Maß an kryptoökonomischer Sicherheit. Der positive Kreislauf der wirtschaftlichen Sicherheit: Die Anreize, die wir in diesem Abschnitt besprechen, staking und FFO, haben eine Wirkung, die über die Stärkung der Sicherheit hinausgeht DONs. Sie versprechen, das in Gang zu setzen, was wir einen positiven Kreislauf der wirtschaftlichen Sicherheit nennen. Superlineare staking-Auswirkungen (und andere Skaleneffekte) führen zu geringeren Betriebskosten Kosten, wenn die Sicherheit eines DON wächst. Niedrigere Kosten locken mehr Benutzer zum DON,Erhöhung der Gebührenzahlungen. Ein Anstieg der Gebührenzahlungen sorgt weiterhin für einen Wachstumsanreiz Netzwerk, das den positiven Kreislauf fortsetzt. Wir glauben, dass der positive Kreislauf der wirtschaftlichen Sicherheit nur ein Beispiel dafür ist Größenvorteile und Netzwerkeffekte sind unter anderem die, die wir später in diesem Abschnitt besprechen. Abschnittsorganisation: Das Abstecken stellt erhebliche technische und konzeptionelle Herausforderungen dar Wir haben einen Mechanismus mit neuartigen Funktionen entwickelt. Das Abstecken wird daher sein Unser Hauptaugenmerk in diesem Abschnitt. Wir geben einen Überblick über den staking-Ansatz, den wir in diesem Dokument in Abschnitt 9.1 vorstellen, gefolgt von einer ausführlichen Diskussion in den Abschnitten 9.2 bis 9.5. Wir stellen das IFF vor in Abschnitt 9.6. In Abschnitt 9.7 präsentieren wir eine zusammenfassende Ansicht der Chainlink Netzwerkanreize. In Abschnitt 9.8 diskutieren wir den positiven Kreislauf der wirtschaftlichen Sicherheit, den unser vorgeschlagener staking-Ansatz für oracle-Netzwerke bewirken kann. Abschließend beschreiben wir kurz weitere Potenziale Auswirkungen, die das Wachstum des Chainlink-Netzwerks vorantreiben, in Abschnitt 9.9. 9.1 Absteckübersicht Das hier vorgestellte staking-Mechanismusdesign umfasst, wie oben erwähnt, ein interaktives Protokoll zwischen oracle-Knoten, das die Lösung von Inkonsistenzen im ermöglicht Berichterstattung über externe Daten. Durch das Abstecken soll ehrliches Verhalten von rationalen oracle-Knoten gewährleistet werden. Wir können daher einen Gegner, der ein staking-Protokoll angreift, als Folgendes modellieren: Bestechung: Die Strategie des Gegners besteht darin, oracle-Knoten durch finanzielle Anreize zu korrumpieren. Der Gegner kann aus einer erfolgreichen Manipulation möglicherweise finanzielle Mittel gewinnen mit einem oracle-Bericht, z. B. bieten Sie an, den daraus resultierenden Gewinn mit beschädigten Knoten zu teilen. Mit unserem staking-Mechanismusdesign verfolgen wir gleichzeitig zwei ehrgeizige Ziele: 1. Einem mächtigen Gegner widerstehen: Der staking-Mechanismus soll schützen oracle Netzwerke gegen eine breite Klasse von Gegnern, die in der Lage sind, komplexe, bedingte Bestechungsstrategien, einschließlich potenzieller Bestechung, bei der Bestechungsgelder angeboten werden an oracles, deren Identität im Nachhinein festgestellt wird (bietet z. B. Bestechungsgelder an oracles werden zufällig für eine Warnung mit hoher Priorität ausgewählt). Während andere oracle Designs haben eine begrenzte Anzahl von Angriffen in Betracht gezogen, ohne die vollen Fähigkeiten eines realistischen Angriffs auszuüben Gegner, nach unserem besten Wissen der von uns eingeführte gegnerische Mechanismus Hier geht es erstmals explizit um eine breite Palette von Bestechungsstrategien und -darstellungen Widerstand in diesem Modell. Unser Modell geht davon aus, dass es neben dem Angreifer auch Knoten gibt wirtschaftlich rational (im Gegensatz zu ehrlich), und wir gehen von der Existenz eines aus Quelle der Wahrheit, die für den typischen Gebrauch unerschwinglich teuer, aber verfügbar ist im Falle einer Meinungsverschiedenheit (weiter unten besprochen). 2. Erzielung einer superlinearen staking-Wirkung: Unser Ziel ist es, sicherzustellen, dass ein oracle Netzwerk aus rationalen Agenten Berichte erstellt Ehrlich gesagt, selbst in Anwesenheit eines Angreifers mit einem Budget, das superlinear istam gesamten vom gesamten Netzwerk eingezahlten Anteil. In bestehenden staking-Systemen, wenn Da jeder der n Knoten $d einsetzt, kann ein Angreifer eine glaubwürdige Bestechung ausstellen, die verlangt dass Knoten sich im Gegenzug für eine Zahlung von etwas mehr als unehrlich verhalten \(d to each node, using a total budget of about \)dn. Das ist schon eine hohe Messlatte Der Angreifer muss über ein liquides Budget in der Größenordnung der kombinierten Einlagen verfügen alle Staker im Netzwerk. Unser Ziel ist ein noch stärkeres Maß an wirtschaftlicher Sicherheit als diese ohnehin schon erhebliche Hürde. Unser Ziel ist es, das erste staking-System zu entwerfen Das kann Sicherheit für einen allgemeinen Angreifer mit einem superlinearen Budget in n erreichen. Während praktische Überlegungen möglicherweise eine geringere Wirkung erzielen, wie wir weiter unten erörtern, Unser vorläufiger Entwurf erfüllt eine konkurrenzfähige Budgetanforderung von mehr als $dn2/2, d. h. quadratische Skalierung in n, was Bestechung sogar weitgehend unpraktisch macht wenn Knoten nur mäßige Beträge einsetzen. Um diese beiden Ziele zu erreichen, ist eine innovative Kombination der Anreizgestaltung erforderlich und Kryptographie. Schlüsselideen: Unser staking-Ansatz basiert auf einer Idee, die wir Watchdog-Priorität nennen. Ein Bericht, der von einem Chainlink oracle Netzwerk generiert und an einen vertrauenden Vertrag gesendet wird (z. B. zu einem Vermögenspreis) wird aus einzelnen Berichten aggregiert, die von teilnehmenden Knoten bereitgestellt werden (z. B. durch Ermittlung des Medians). Typischerweise ein Service-Level-Agreement (SLA) legt akzeptable Abweichungsgrenzen für Berichte fest, d. h. wie weit der Bericht eines Knotens gehen kann vom aggregierten Bericht abweichen und inwieweit die aggregierte Meldung zulässig sein soll vom wahren Wert abweichen, um als richtig angesehen zu werden. In unserem staking-System kann jeder oracle-Knoten für eine bestimmte Berichtsrunde als agieren ein Watchdog, der eine Warnung auslöst, wenn er glaubt, dass der Gesamtbericht falsch ist. In jedem In der Berichtsrunde wird jedem oracle-Knoten eine öffentliche Priorität zugewiesen, die die bestimmt Reihenfolge, in der die Warnung (falls vorhanden) verarbeitet wird. Unser Mechanismus zielt auf Belohnung ab Konzentration, was bedeutet, dass der Watchdog mit der höchsten Priorität, der einen Alarm auslöst, die verdient gesamte Belohnung, die durch die Beschlagnahmung der Einlagen fehlerhafter Knoten erzielt wird. Unsere staking-Systemdesigns umfassen zwei Ebenen: die erste, die Standardebene, und die zweite, Backstop-Stufe. Die erste Ebene ist das Netzwerk oracle selbst, eine Menge von n Knoten. (Der Einfachheit halber Wir gehen davon aus, dass n ungerade ist.) Wenn eine Mehrheit der Knoten falsche Werte meldet, wird ein Watchdog im Für die erste Ebene besteht ein starker Anreiz, eine Warnung auszulösen. Wenn eine Warnung ausgelöst wird, erfolgt die Berichterstattung Die Entscheidung des Netzwerks wird dann auf eine zweite Ebene eskaliert – ein kostenintensives System mit maximaler Zuverlässigkeit, das vom Benutzer in der Netzwerk-Service-Level-Vereinbarung spezifiziert werden kann. Dies könnte beispielsweise ein System sein, das nur aus Knoten mit starken Knoten besteht historische Zuverlässigkeitswerte oder einer, der eine Größenordnung mehr als oracles hat die erste Stufe. Darüber hinaus können, wie in Abschnitt 9.4.3 besprochen, DECO oder Town Crier dienen als leistungsstarke Werkzeuge zur Gewährleistung einer effizienten und schlüssigen Rechtsprechung auf der zweiten Ebene. Der Einfachheit halber gehen wir daher davon aus, dass dieses System der zweiten Ebene zu einem korrekten Bericht gelangt Wert. Auch wenn es attraktiv erscheinen mag, sich bei der Generierung aller Berichte einfach auf die zweite Ebene zu verlassen, Der Vorteil unseres Designs besteht darin, dass es die Sicherheitseigenschaften des zuverlässig erfülltZweitschichtsystem, wobei im typischen Fall nur die Betriebskosten des Systems bezahlt werden First-Tier-System. Die Watchdog-Priorität führt zu einer superlinearen staking-Auswirkung auf die folgende Weise: Wenn die Das Netzwerk der ersten Ebene oracle gibt ein falsches Ergebnis und eine Reihe von Watchdog-Knoten aus Alarm, der Anreizmechanismus staking belohnt den Watchdog mit der höchsten Priorität mehr als $dn/2 aus den Einlagen der (mehrheitlich) sich schlecht benehmenden Knoten entnommen. Die Die Gesamtvergütung liegt somit in den Händen dieses einzigen Wachhundes, der daher bestimmt das Minimum, das ein Gegner einem potenziellen Wachhund versprechen muss Anreize schaffen, nicht zu alarmieren. Da unser Mechanismus sicherstellt, dass jeder oracle das erhält Möglichkeit, als Wachhund zu fungieren, wenn die Wachhunde mit höherer Priorität ihre Bestechungsgelder angenommen haben (und beschlossen, nicht zu alarmieren), muss der Gegner daher ein Bestechungsgeld von mehr als anbieten $dn/2 an jeden Knoten, um zu verhindern, dass eine Warnung ausgelöst wird. Da es n Knoten gibt, ist die Das für eine erfolgreiche Bestechung erforderliche Budget des Gegners beträgt mehr als $dn2/2 ist quadratisch in der Anzahl n der Knoten im Netzwerk. 9.2 Hintergrund Unser Ansatz für staking basiert auf Forschungen in den Bereichen Spieltheorie und Spielmechanismus Design (MD) (für eine Lehrbuchreferenz siehe [177]). Spieltheorie ist das mathematisch formalisierte Untersuchung der strategischen Interaktion. In diesem Zusammenhang ist ein Spiel ein Modell dafür eine Interaktion, typischerweise in der realen Welt, die die verfügbaren Aktionen kodifiziert Teilnehmer am Spiel, sogenannte Spieler. Ein Spiel gibt auch die erzielten Auszahlungen an durch die einzelnen Spieler – Belohnungen, die von den gewählten Aktionen eines Spielers und dem abhängen Aktionen der anderen Spieler. Vielleicht das bekannteste Beispiel für ein im Spiel untersuchtes Spiel Theorie ist das Gefangenendilemma [178]. Spieltheoretiker zielen im Allgemeinen darauf ab, zu verstehen das Gleichgewicht oder die Gleichgewichte (falls vorhanden), die in einem bestimmten Spiel dargestellt werden. Ein Gleichgewicht ist eine Reihe von Strategien (eine für jeden Spieler), so dass kein Spieler eine höhere erreichen kann sich auszahlen, indem sie einseitig von ihrer Strategie abweichen. Mechanismusdesign hingegen ist die Wissenschaft, Anreize so zu gestalten, dass die Das Gleichgewicht einer Interaktion (und des damit verbundenen Spiels) hat eine wünschenswerte Eigenschaft. MD kann als das Gegenteil der Spieltheorie angesehen werden: Die kanonische Frage im Spiel Die Theorie lautet: „Wie wird das Gleichgewicht angesichts der Anreize und des Modells aussehen?“ In MD ist die Die Frage lautet stattdessen: „Welche Anreize führen zu einem Spiel mit einem wünschenswerten Gleichgewicht?“ Ein typisches Ziel eines Mechanismusdesigners besteht darin, einen „anreizkompatiblen“ Mechanismus zu schaffen, was bedeutet, dass die Teilnehmer des Mechanismus (z. B. eine Auktion oder andere Informationen Erhebungssystem [228]) werden dazu angeregt, die Wahrheit über eine Angelegenheit zu berichten (z. B. wie wie sehr sie einen bestimmten Gegenstand schätzen). Die Vickrey-Auktion (Zweiterpreis) ist vielleicht die bekanntester anreizkompatibler Mechanismus, bei dem die Teilnehmer versiegelte Gebote abgeben für einen Artikel und der Meistbietende erhält den Zuschlag für den Artikel, zahlt aber den zweithöchsten Preis [214]. Kryptoökonomie ist eine domänenspezifische Form von MD, die Kryptografie nutzt Techniken zur Schaffung wünschenswerter Gleichgewichte innerhalb dezentraler Systeme. Bestechung und Absprachen stellen im gesamten Medizinbereich erhebliche Herausforderungen dar. Nahezu alle Mechanismen brechen bei Absprachen, die als Nebenverträge definiert werden.zwischen den an einem Mechanismus beteiligten Parteien [125, 130]. Ein noch schwierigeres Problem stellt Bestechung dar, bei der eine externe Partei neuartige Anreize ins Spiel bringt als Absprachen; Absprachen können als Sonderfall der Bestechung unter Wild angesehen werden Teilnehmer. Blockchain-Systeme können oft als Spiele mit monetären (kryptowährungsbasierten) Auszahlungen konzipiert werden. Ein einfaches Beispiel ist das Proof-of-Work-Mining: Miner verfügen über einen Aktionsraum in dem sie die hashRate auswählen können, mit der nach Blöcken geschürft werden soll. Die Auszahlung des Bergbaus ist eine garantierte negative Belohnung (Kosten für Strom und Ausrüstung) plus eine stochastische Belohnung positive Belohnung (Mining-Subvention), die von der Anzahl anderer aktiver Miner abhängt [106, 172] und Transaktionsgebühren. Crowdsourcing-oracles wie SchellingCoin [68] sind ein weiteres Beispiel: Der Aktionsbereich ist die Menge möglicher Berichte, die ein oracle senden kann Die Auszahlung ist die durch den oracle-Mechanismus festgelegte Belohnung, z. B. kann die Zahlung davon abhängen darüber, wie nah der Bericht eines oracle am Median der anderen Berichte liegt [26, 68, 119, 185]. Blockchain-Spiele bieten zahlreiche Möglichkeiten für Absprachen und Bestechungsangriffe. in der Tat, smart contracts können solche Angriffe sogar erleichtern [96, 165]. Vielleicht das bekannteste Bestechungsangriff auf Crowdsourcing-oracles ist der P-plus-Epsilon-Angriff [67]. Dieser Angriff entsteht im Kontext eines SchellingCoin-ähnlichen Mechanismus, bei dem Spieler boolesche Berichte (d. h. falsch oder wahr) einreichen und mit p belohnt werden, wenn sie damit einverstanden sind Mehrheitsvorlage. Bei einem P-plus-Epsilon-Angriff verspricht der Angreifer glaubhaft, Z. B. zahlen Sie Benutzern genau dann $p + ϵ für eine falsche Abstimmung, wenn die Mehrheitsabgabe wahr ist. Das Ergebnis ist ein Gleichgewicht, in dem alle Akteure einen Anreiz haben, falsche Angaben zu machen unabhängig davon, was andere Spieler tun; Folglich kann der Bestechungsgelder die Knoten induzieren durch sein versprochenes Bestechungsgeld, falsche Angaben zu machen, ohne das Bestechungsgeld tatsächlich zu zahlen (!). Die Erforschung anderer Bestechungsstrategien im Zusammenhang mit oracles – und insbesondere oracles, die nicht durch Crowdsourcing finanziert werden – beschränkte sich jedoch auf relativ schwache kontradiktorische Strategien Modelle. Beispielsweise haben Forscher im PoW-Umfeld die Ergebnisabhängigkeit untersucht Bestechungsgelder, d. h. Bestechungsgelder, die nur gezahlt werden, wenn eine Zielnachricht erfolgreich zensiert wurde und dies nicht der Fall ist erscheinen in einem Block, unabhängig von der Aktion eines einzelnen Miners [96, 165]. Im Fall Von oracles sind uns jedoch außer dem p-plus-epsilon-Angriff nur Arbeiten in bekannt Ein streng begrenztes Bestechungsmodell, bei dem ein Bestechungsgelder ein Bestechungsgeld sendet, das an eine Bedingung geknüpft ist Es kommt auf die Aktion des einzelnen Spielers an, nicht auf das daraus resultierende Ergebnis. Hier skizzieren wir Entwürfe von Mechanismen zur Informationserhebung, die Anreiz bleiben auch in einem starken kontradiktorischen Modell kompatibel, wie im nächsten Unterabschnitt beschrieben. 9.3 Modellannahmen In diesem Unterabschnitt erklären wir, wie wir das Verhalten und die Fähigkeiten von Spielern modellieren Unser System, insbesondere oracle-Knoten der ersten Ebene, Knoten der zweiten Ebene (Entscheidung) Schicht und Gegner.9.3.1 Anreizmodell der ersten Stufe: Rationale Akteure Viele blockchain-Systeme verlassen sich aus Sicherheitsgründen auf die Annahme einiger Ehrlichkeit teilnehmende Knoten. Knoten werden als ehrlich definiert, wenn sie sich überhaupt an das Protokoll halten wenn es nicht in ihrem finanziellen Interesse liegt, dies zu tun. Typischerweise Proof-of-Work-Systeme Um ehrlich zu sein, erfordern Proof-of-Stake-Systeme in der Regel 2/3 oder mehr des gesamten teilnehmenden Einsatzes, um ehrlich zu sein, und sogar Layer-2-Systeme mögen dies Arbitrum [141] erfordert mindestens einen einzigen ehrlichen Teilnehmer. Bei der Modellierung unseres staking-Mechanismus gehen wir von einer viel schwächeren Annahme aus. (Sein Klare, schwächere Annahmen bedeuten stärkere Sicherheitseigenschaften und sind daher vorzuziehen.) Wir gehen davon aus, dass der Gegner einige (Minderheiten) korrumpiert hat, d. h. kontrolliert. Bruchteil der oracle-Knoten der ersten Ebene. Wir modellieren die verbleibenden Knoten nicht als ehrliche Agenten, sondern als rationale Erwartungsnutzenmaximierer. Diese Knoten handeln ausschließlich nach eigennützigen finanziellen Anreizen und wählen Aktionen aus, die zu einem erwarteten finanziellen Ergebnis führen gewinnen. Zum Beispiel, wenn einem Knoten ein Bestechungsgeld angeboten wird, das größer ist als die daraus resultierende Belohnung Wer sich ehrlich verhält, nimmt das Bestechungsgeld an. Hinweis zu gegnerischen Knoten: In Übereinstimmung mit der Vertrauensmodellierung, die für üblich ist Bei dezentralen Systemen gehen wir davon aus, dass alle Knoten rational sind, d. h. nach Maximierung streben Nettoumsatz, anstatt von einem böswilligen Gegner kontrolliert zu werden. Unsere Ansprüche jedoch: insbesondere superlinearer oder quadratischer staking Stoß – asymptotisch vorausgesetzt dass die Menge der kontradiktorisch kontrollierten Knoten höchstens (1/2 −c)n beträgt, für einige positive konstant c. 9.3.2 Beurteilungsmodell der zweiten Stufe: Korrektheit durch Annahme Denken Sie daran, dass dies ein wichtiges Merkmal unseres staking-Mechanismus ist, der zur Gewährleistung der Sicherheit beiträgt gegen rationale Knoten ist sein zweitrangiges System. In unserem vorgeschlagenen staking-Mechanismus kann jeder oracle eine Warnung auslösen, die darauf hinweist Es geht davon aus, dass die Ausgabe des Mechanismus falsch ist. Eine Warnung führt zu einer hohen Vertrauenswürdigkeit Zweitschichtiges System, das das korrekte Ergebnis aktiviert und meldet. Somit eine Schlüsselmodellierung Voraussetzung für unser Vorgehen ist eine korrekte Rechtsprechung, also eine korrekte Berichterstattung durch die zweitrangiges System. Unser staking-Modell geht von einem System der zweiten Ebene aus, das als unbestechliche, höchst zuverlässige Quelle der Wahrheit fungiert. Ein solches System dürfte teuer und langsam sein für den typischen Fall ungeeignet. Im Gleichgewichtsfall jedoch, d. h. wann Das System der ersten Schicht funktioniert ordnungsgemäß, das System der zweiten Schicht wird nicht aufgerufen. Stattdessen erhöht seine Existenz die Sicherheit des gesamten oracle-Systems, indem es Folgendes bereitstellt: Hochsichere Rücklaufsperre. Der Einsatz einer vertrauenswürdigen und kostenintensiven Entscheidungsebene ähnelt dem Berufungsverfahren das Herzstück der meisten Justizsysteme. Es ist auch bereits im Design von oracle üblich Systeme, z. B. [119, 185]. Wir diskutieren kurz Ansätze zur Realisierung der zweiten Ebene in unserem Mechanismus in Abschnitt 9.4.3.Unser staking-Protokoll nutzt die angenommene korrekte Entscheidung des Second-Tier-Systems als glaubwürdige Bedrohung, um eine korrekte Berichterstattung durch oracle-Knoten durchzusetzen. Das Protokoll konfisziert einen Teil oder den gesamten Anteil der oracle-Knoten, die Berichte generieren, die durch identifiziert werden das System der zweiten Stufe als falsch. Oracle-Knoten werden so von Fehlverhalten abgeschreckt durch die daraus resultierende Geldstrafe. Dieser Ansatz ähnelt im Grunde dem, der in verwendet wird optimistische rollups, z. B. [141, 10]. 9.3.3 Gegnerisches Modell Unser staking-Mechanismus ist darauf ausgelegt, wahrheitsgemäße Informationen zu ermitteln und gleichzeitig Sicherheit vor einer breiten, klar definierten Klasse von Gegnern zu gewährleisten. Es stellt eine Verbesserung gegenüber früheren Arbeiten dar, die entweder ein explizites Gegnermodell weglassen oder sich auf enge Unterklassen von Gegnern konzentrieren, z. B. den oben diskutierten p-plus-epsilon-Gegner. Unser Ziel ist es, ein staking zu entwerfen Mechanismus mit formal nachgewiesener Sicherheit gegen das gesamte Spektrum wahrscheinlicher Gegner in der Praxis anzutreffen sind. Wir modellieren unseren Gegner so, als hätte er ein festes (parametrierbares) Budget, das mit bezeichnet wird $B. Der Gegner kann mit jedem oracle in individuell und vertraulich kommunizieren das Netzwerk und kann heimlich jeder Einzelperson oracle die garantierte Zahlung eines Bestechungsgeldes anbieten abhängig von öffentlich beobachtbaren Ergebnissen des Mechanismus. Ergebnisse bestimmend Bestechungsgelder können beispielsweise den vom oracle gemeldeten Wert oder alle öffentlichen Nachrichten umfassen von jedem oracle an den Mechanismus gesendet (z. B. eine Warnung), die von anderen gemeldeten Werte oracles und der vom Mechanismus ausgegebene Wert. Kein Mechanismus kann gegen einen Angreifer mit unbegrenzten Fähigkeiten schützen. Daher halten wir einige Verhaltensweisen für unrealistisch oder außerhalb des Rahmens. Wir gehen von unserem Angreifer aus kann standardmäßige kryptografische Primitive nicht knacken und hat, wie oben erwähnt, eine feste (if potenziell großes) Budget $B. Wir gehen weiterhin davon aus, dass der Gegner nicht kontrolliert Kommunikation im Netzwerk oracle, insbesondere dass sie sich nicht wesentlich verzögern darf Datenverkehr zwischen Knoten der ersten und/oder zweiten Ebene. (Ob der Gegner eine solche Kommunikation beobachten kann, hängt vom jeweiligen Mechanismus ab, wie wir weiter unten erläutern.) Informell gehen wir jedoch, wie oben erwähnt, davon aus, dass der Gegner: (1) korrupt sein kann ein Bruchteil von oracle Knoten ((1/2 −c)-Bruchteil für eine Konstante c), d. h. vollständige Kontrolle ihnen, und (2) Bestechungsgelder an alle gewünschten Knoten anbieten, mit garantierter Zahlungskontingent auf vom Gegner vorgegebenen Ergebnissen, wie oben beschrieben. Wir bieten zwar kein formales Modell oder keine vollständige Taxonomie des Gesamtumfangs des Gegners an In diesem Whitepaper stellen wir Ihnen die verschiedenen Möglichkeiten der Bestechung vor. Hier finden Sie Beispiele dafür Bestechungsgelder, die unser Modell umfasst. Der Einfachheit halber gehen wir davon aus, dass oracles Boolesche Werte ausgeben Berichte, deren korrekter Wert (w.l.o.g.) wahr ist und als das ein Endergebnis berechnet wird ein Aggregat dieser Berichte, das von einem konsumierenden smart contract verwendet werden soll. Die des Bestechers Ziel ist es, dass das Endergebnis falsch, also falsch, ist. • Bedingungslose Bestechung: Der Bestechungsgelder bietet jedem oracle Bestechungsgeld $b an, der falsche Angaben macht. • Probabilistischer Bestechungsgelder: Bestechungsgelder bietet Bestechungsgeld $b mit einer gewissen Wahrscheinlichkeit q jedem oracle an das meldet falsch.• Bedingter Bestecher mit falschem Ergebnis: Der Bestecher bietet jedem oracle, der „falsch“ meldet, Bestechung $b an, vorausgesetzt, dass das Endergebnis falsch ist. • Kein Benachrichtigungsbedingter Bestechungsgelder: Der Bestechungsgelder bietet jedem oracle, der sich meldet, Bestechungsgeld $b an false, solange keine Warnung ausgelöst wird. • p-plus-epsilon Briber: Briber bietet Bestechung $b an jeden oracle an, der falsch als meldet solange die Mehrheit der oracles nicht falsch meldet. • Potenzieller Bestechungsgelder: Der Bestechungsgelder bietet dem ausgewählten oracle Bestechungsgelder in Höhe von $b im Voraus an für eine zufällige Rolle und meldet falsch. In unserem vorgeschlagenen staking-Protokoll alle Knoten fungieren als potenzielle Watchdogs, und wir können diese Randomisierung zeigen Die Festlegung von Überwachungsprioritäten ist nicht geeignet für potenzielle Bestechung. Viele Proof-of-Work-, proof-of-stake- und autorisierte Systeme sind anfällig für potenzielle Fehler Allerdings handelt es sich um Bestechung, was zeigt, wie wichtig es ist, sie in unserem Gegner zu berücksichtigen Modell und stellen sicher, dass unsere staking-Protokolle dafür widerstandsfähig sind. Siehe Anhang E für weitere Details. 9.3.4 Wie viel kryptoökonomische Sicherheit ist ausreichend? Ein rationaler Gegner wird nur dann Geld ausgeben, um ein System anzugreifen, wenn er einen Gewinn erzielen kann größer als seine Ausgaben. Also für unser kontradiktorisches Modell und den vorgeschlagenen staking Mechanismus kann $B als Maß für den potenziellen Gewinn angesehen werden, den ein Gegner erzielen kann aus vertrauenswürdigen smart contracts zu extrahieren, indem ein oracle-Netzwerk beschädigt und verursacht wird einen falschen Bericht oder eine Reihe von Berichten zu erstellen. Bei der Entscheidung, ob ein oracle Netzwerk Ein Benutzer sollte für seine Zwecke ein ausreichendes Maß an kryptoökonomischer Sicherheit bieten Bewerten Sie das Netzwerk aus dieser Perspektive. Für plausible Gegner in praktischen Situationen gehen wir davon aus, dass $B im Allgemeinen so sein wird wesentlich kleiner als das Gesamtvermögen der smart contracts. In den meisten Fällen ist es Es ist für einen Gegner unmöglich, diese Vermögenswerte in ihrer Gesamtheit zu extrahieren. 9.4 Absteckmechanismus: Skizze Hier stellen wir die Hauptideen und die allgemeine Struktur des staking-Mechanismus vor überlegen gerade. Zur Vereinfachung der Präsentation beschreiben wir ein einfaches, aber langsames Verfahren (Mehrrunden-)Protokoll in diesem Unterabschnitt. Wir stellen jedoch fest, dass dieses Schema recht ist praktisch. Angesichts der wirtschaftlichen Garantien, die der Mechanismus bietet, d. h. der Bestrafung fehlerhafter Knoten und des daraus resultierenden Anreizes für diese, sind viele Benutzer möglicherweise dazu bereit Nehmen Sie Berichte optimistisch an. Mit anderen Worten, solche Benutzer können Berichte vorher akzeptieren mögliche Entscheidung der zweiten Instanz. Benutzer, die Berichte nicht optimistisch annehmen möchten, können bis zum Protokoll warten Die Ausführung wird beendet, d. h. bis eine mögliche Eskalation zur zweiten Ebene erfolgt. Dies, kann jedoch die Bestätigungszeit für Berichte erheblich verlangsamen. Wir daher kurzAbbildung 15: Schematische Darstellung des Schemas staking mit Alarmierung. In diesem Beispiel ist 1⃝eine Mehrheit der Knoten sind beschädigt/bestochen und geben einen falschen Wert ˜r statt des richtigen aus Meldewert r. Der Watchdog-Knoten 2 sendet eine Warnung an das Komitee der zweiten Ebene. welches 3⃝den korrekten Berichtswert r ermittelt und ausgibt, was zu beschädigten Knoten führt ihre Einlagen verfallen – jeweils $d an den Watchdog-Knoten 4⃝. Skizzieren Sie einige Optimierungen, die zu einer schnelleren (Einzelrunde), wenn auch etwas mehr, führen komplexes Design in Abschnitt 9.5. Denken Sie daran, dass die erste Stufe in unserem staking-Mechanismus aus dem grundlegenden oracle besteht. Netzwerk selbst. Die Hauptstruktur unseres oben beschriebenen Mechanismus besteht darin, dass in jeder Runde Jeder Knoten kann mit einer gewissen Priorität als „Watchdog“ fungieren und hat daher die Möglichkeit dazu Lösen Sie eine Warnung aus, wenn der Mechanismus zu einer falschen Ausgabe ˜r und nicht zu einer korrekten Ausgabe gelangt ein r. Diese Warnung führt zu einer Lösung der zweiten Ebene, von der wir annehmen, dass sie zu einer korrekten Lösung führt Bericht. Knoten mit falschen Meldungen werden im gleichen Sinne bestraft wie ihre Einsätze aufgeschlitzt und an Wachhunde vergeben. Diese Grundstruktur ist in oracle-Systemen üblich. wie z. B. [119, 185]. Die wichtigste Neuerung in unserem Design, die oben kurz erwähnt wurde, besteht darin, dass jeder Knoten vorhanden ist wird bei der Anordnung potenzieller Watchdogs eine eindeutige Priorität zugewiesen. Das heißt, Wachhunde erhalten die Möglichkeit, in der Reihenfolge der Priorität zu alarmieren. Denken Sie daran, dass, wenn ein Knoten das hat Wenn es die höchste Priorität hat, eine Warnung auszulösen, erhält es für jedes Fehlverhalten die gekürzte Kaution in Höhe von $d Knoten, für insgesamt mehr als \(dn/2 = \)d × n/2, da ein falscher Bericht impliziert a Mehrheit der fehlerhaften Knoten. Folglich muss der Gegner mindestens diese Belohnung zahlen einen beliebigen Knoten bestechen. Um also die Mehrheit der Knoten zu bestechen, muss der Gegner a zahlen große Bestechungsgelder für die Mehrheit der Knoten, nämlich streng genommen mehr als $dn2/2. Wie Alarmierung und Watchdog-Eskalation funktionieren, zeigen wir schematisch in Abb. 15.9.4.1 Weitere Details zum Mechanismus Das bestechungsresistente System, das wir nun ausführlicher beschreiben, ist eine vereinfachte Skizze davon die zweistufige Konstruktion, die wir bauen wollen. Unser Hauptaugenmerk wird auf der Beschreibung liegen das Netzwerk der ersten Ebene (im Folgenden einfach „Netzwerk“, soweit aus dem Kontext klar) entlang mit seinem Anreizmechanismus und dem Verfahren zur Eskalation in die zweite Ebene. Stellen Sie sich ein Chainlink Netzwerk vor, das aus n oracle Knoten besteht, die dafür verantwortlich sind regelmäßig (z. B. einmal pro Minute) einen booleschen Wert melden (z. B. ob der Markt Die Kapitalisierung von BTC übersteigt die von ETH). Als Teil des staking-Mechanismus, nodes muss zwei Anzahlungen leisten: eine Anzahlung in Höhe von $d, die im Falle einer Meinungsverschiedenheit gekürzt werden kann mit der Mehrheit und einer Überwachungseinlage von $dw, die im Falle eines Fehlers gekürzt werden kann Eskalation. Wir gehen davon aus, dass die Knoten die Einreichungen anderer Knoten nicht kopieren können, z. B. durch ein Commit-Reveal-Schema, wie in Abschnitt 5.3 beschrieben. In jeder Runde zuerst die Knoten verpflichten sich zu ihrem Bericht, und sobald alle Knoten sich verpflichtet haben (oder eine Zeitüberschreitung abgelaufen ist), Knoten offenbaren ihre Berichte. Für jeden zu generierenden Bericht erhält jeder Knoten außerdem eine zufällig ausgewählte Watchdog-Priorität zwischen 1 und n, wobei 1 die höchste Priorität hat. Diese Priorität ermöglicht die Konzentration der Belohnung in den Händen eines Wachhundes. Nachdem alle Berichte öffentlich sind, Es folgt eine Alarmierungsphase. Über eine Folge von n (synchronen) Runden wird der Knoten mit Priorität i hat die Möglichkeit, in Runde i zu alarmieren. Betrachten wir die möglichen Ergebnisse des Mechanismus, nachdem Knoten aufgedeckt wurden ihre Berichte. Gehen wir wiederum von einem binären Bericht aus und nehmen wir an, dass der korrekte Wert „true“ und „true“ ist das Falsche ist falsch. Nehmen wir außerdem an, dass der Mechanismus der ersten Ebene Folgendes ausgibt Mehrheitswert, der von den Knoten als Abschlussbericht ausgegeben wird r. Es gibt drei mögliche Ergebnisse des Mechanismus: • Vollständige Übereinstimmung: Im besten Fall stimmen die Knoten vollständig überein: alle Knoten verfügbar sind und einen zeitnahen Bericht mit dem gleichen Wert r (entweder wahr) vorgelegt haben oder falsch). In diesem Fall muss das Netzwerk r nur an vertrauende Verträge weiterleiten und belohnen Sie jeden Knoten mit einer festen Zahlung $p pro Runde, die viel kleiner ist als $d. • Teilweise Übereinstimmung: Es ist möglich, dass einige Knoten offline sind oder Uneinigkeit darüber besteht, welcher Wert richtig ist, aber die meisten Knoten melden „wahr“ und nur „a“. Minderheitenberichte sind falsch. Auch dieser Fall ist unkompliziert. Der Mehrheitswert (true) wird berechnet, was zu einem korrekten Bericht r führt. Alle Knoten, die r gemeldet haben, sind mit $p belohnt, während die oracles, die falsch gemeldet haben, ihre Einzahlungen haben geringfügig gekürzt, z. B. um 10 Pence. • Warnung: Für den Fall, dass ein Watchdog glaubt, dass die Ausgabe des Netzwerks falsch ist, Es löst öffentlich eine Warnung aus und eskaliert den Mechanismus an das Netzwerk der zweiten Ebene. Es gibt dann zwei mögliche Ergebnisse: – Korrekte Warnung: Wenn das Netzwerk der zweiten Ebene bestätigt, dass die Ausgabe desAbbildung 16: Erhöhung der Kosten für Bestechungsgelder durch konzentrierte Alarmierungsprämien. Eine Bestechung Der Gegner muss jeden Knoten mit mehr als der Belohnung bestechen, die er durch die Alarmierung erhalten kann (dargestellt als roter Balken). Wenn alarmierende Belohnungen geteilt werden, kann diese Belohnung relativ sein klein. Konzentrierte Alarmierungsbelohnungen erhöhen die Belohnung, die jeder einzelne Knoten erhalten kann erhalten (hoher roter Balken). Folglich die Gesamtauszahlung des Gegners für eine realisierbare Bestechung (graue Bereiche) ist bei konzentrierten als bei geteilten Alarmierungsbelohnungen viel größer. Wenn das Netzwerk der ersten Ebene falsch war, erhält der alarmierende Watchdog-Knoten eine Belohnung bestehend aus allen gekürzten Einlagen und somit mehr als $dn/2. – Fehlerhafte Warnung: Wenn die oracles der zweiten und ersten Ebene übereinstimmen, erfolgt die Eskalation als fehlerhaft betrachtet und der alarmierende Knoten verliert seine $dw-Einzahlung. Bei optimistischer Annahme von Meldungen kommt es nicht zu Watchdog-Alarmen jede Änderung in der Ausführung von Vertrauensverträgen. Für Verträge, die warten sollen Mögliche Schlichtung durch den Ausschuss der zweiten Ebene, Überwachungswarnungen verzögern sich jedoch die Vertragsausführung nicht einfrieren. Es ist auch möglich, in Verträgen einen zu benennen Failover DON für Zeiträume der Entscheidung. 9.4.2 Auswirkungen auf das quadratische Abstecken Die Fähigkeit jedes Knotens, als Watchdog zu fungieren, kombiniert mit einer strengen Knotenpriorität Die Sicherstellung konzentrierter Belohnungen ermöglicht es dem Mechanismus, quadratische staking zu erreichen. Auswirkungen für jede Art von Bestechungsangreifern, die in Abschnitt 9.3.3 beschrieben werden. Denken Sie daran Konkret bedeutet dies in unserem Fall, dass es sich um ein Netzwerk mit n Knoten mit jeweils Einzahlung handelt $d, ein erfolgreicher Bestechungsgelder (einer der oben genannten Arten) muss über ein Budget von mehr als verfügen $dn2/2. Um genau zu sein, muss der Bestecher mindestens (n+1)/2 Knoten korrumpieren, da der Bestecher dies tun muss eine Mehrheit von n Knoten beschädigen (für ungerade n, vorausgesetzt). Somit steht ein Wachhund zur Verfügung Verdienen Sie eine Belohnung von $d(n + 1)/2. Der Bestechungsgelder muss folglich jedem diesen Betrag zahlenKnoten, um sicherzustellen, dass keiner als Watchdog fungiert. Wir arbeiten daran, das formal zu zeigen, wenn der Bestechungsgelder ein Budget von höchstens $d(n2 + n)/2 hat, dann ist das Teilspiel perfektes Gleichgewicht des Spiels zwischen den Bestechungsgeldern und den oracles – mit anderen Worten, dem Gleichgewicht bei Jeder Punkt während des Spiels besteht darin, dass der Bestechungsgelder das Bestechungsgeld nicht ausgibt und dafür Jeder oracle muss seine wahren Werte ehrlich darlegen. Wir haben oben erklärt, wie es möglich ist, dass ein erfolgreicher Bestechungsgelder eine Strafe verlangen kann Das Budget ist deutlich größer als das der Summe der Node-Einlagen. Um dies zu veranschaulichen intuitives Ergebnis, Abb. 16 zeigt die Wirkung konzentrierter Alarmbelohnungen grafisch. Wie wir dort sehen, wird die Belohnung für die Wachhundalarmierung – nämlich die Einlagen – bestochen Knoten, die falsch melden) – wurden auf alle potenziellen Warnungen aufgeteilt, der Gesamtbetrag, der Jeder einzelne Alarmierungsknoten könnte mit einer relativ kleinen Größe in der Größenordnung von rechnen $d. Ein Bestechungsgelder, der wusste, dass eine Auszahlung von mehr als $ d unwahrscheinlich war, konnte ihn gebrauchen eine bedingte Bestechung mit falschem Ergebnis, um jeden von n Knoten mit etwas mehr als zu bestechen $d + ϵ. Entgegen der Intuition zeigt Abb. 16, dass es sich um ein System handelt, das eine Belohnung breit verteilt unter den Knoten, die eine Warnung signalisieren, ist weitaus schwächer als einer, der die Belohnung konzentriert die Hände eines einzigen Wachhundes. Beispielparameter: Betrachten Sie ein Netzwerk (der ersten Ebene) mit jeweils n = 100 Knoten Einzahlung von \(d = \)20K. Dieses Netzwerk hätte insgesamt 2 Millionen US-Dollar eingezahlt, würde es aber tun Mit dem Budget \(100M = \)dn2/2 vor Bestechung geschützt sein. Erhöhung der Anzahl oracles ist natürlich effektiver als die Erhöhung von $d und kann dramatische Auswirkungen haben: Ein Netzwerk mit n = 300 Knoten und Einlagen \(d = \)20K wäre gegen a geschützt Bestechung mit einem Budget von bis zu 900 Millionen US-Dollar. Beachten Sie, dass ein staking-System in vielen Fällen die darstellenden smart contracts schützen kann mehr Wert als das angebotene Maß an Bestechungsschutz. Das liegt daran, dass es sich um einen Gegner handelt Ein Angriff auf diese Verträge kann in vielen Fällen nicht den vollen Wert herausholen. Zum Beispiel ein Ein Chainlink-gestützter Vertrag, der einen Wert von 1 Milliarde US-Dollar sichert, erfordert möglicherweise nur eine Sicherheit gegen a Bestechung mit Ressourcen in Höhe von 100 Millionen US-Dollar, weil ein solcher Gegner durchaus einen Gewinn erzielen kann von nur 10 % des Vertragswertes. Hinweis: Die Idee, dass der Wert eines Netzwerks quadratisch wachsen kann, kommt in zum Ausdruck das bekannte Metcalfe-Gesetz [167, 235], das besagt, dass der Wert eines Netzwerks wächst quadratisch mit der Anzahl der verbundenen Einheiten. Metcalfes Gesetz jedoch entsteht durch das Wachstum der Anzahl potenzieller paarweiser Netzwerkverbindungen, ein anderes Phänomen als das, das der quadratischen Auswirkung in unserem Anreiz zugrunde liegt Mechanismus. 9.4.3 Realisierung der zweiten Stufe Zwei Betriebsmerkmale erleichtern die Realisierung einer hochzuverlässigen zweiten Ebene: (1) Eine Beurteilung auf zweiter Ebene sollte in oracle-Netzwerken ein seltenes Ereignis sein und ist daher möglich erheblich kostspieliger sein als der normale Betrieb der ersten Ebene und (2) Annahmeoptimistisch akzeptierte Berichte – oder Verträge, deren Ausführung auf ein Schiedsverfahren warten kann – Die zweite Ebene muss nicht in Echtzeit ausgeführt werden. Diese Funktionen führen zu einer Reihe von Konfigurationsoptionen für die zweite Ebene, um die Anforderungen bestimmter DONs zu erfüllen. Als Beispiel für einen Ansatz kann ein Ausschuss der zweiten Ebene aus Knoten bestehen, die von a ausgewählt werden DON (d. h. erste Ebene) von den dienstältesten und zuverlässigsten Knoten im Chainlink Netzwerk. Neben erheblicher einschlägiger Betriebserfahrung verfügen die Betreiber dieser Knoten haben einen beträchtlichen impliziten Anreiz im FFO, der einen Wunsch motiviert um sicherzustellen, dass das Chainlink-Netzwerk äußerst zuverlässig bleibt. Sie haben es auch öffentlich gemacht verfügbare Leistungshistorien, die Transparenz über ihre Zuverlässigkeit bieten. Es ist erwähnenswert, dass Knoten der zweiten Ebene keine Teilnehmer des Netzwerks der ersten Ebene sein müssen kann Fehler über mehrere First-Tier-Netzwerke hinweg beurteilen. Knoten in einem bestimmten DON können eine Menge von n′ solcher vorab festlegen und sich öffentlich dazu verpflichten Knoten bilden das zweitrangige Komitee für dieses DON. Zusätzlich DON Knoten veröffentlichen einen Parameter k′ ≤n′, der die Anzahl der Stimmen der zweiten Ebene bestimmt erforderlich, um einen Knoten der ersten Ebene zu bestrafen. Wenn für einen bestimmten Bericht eine Warnung generiert wird, Die Mitglieder der zweiten Ebene stimmen über die Richtigkeit der jeweils angegebenen Werte ab der Knoten der ersten Ebene. Jeder Knoten der ersten Stufe, der k′ negative Stimmen erhält, verliert seine Einzahlungen an den Watchdog-Knoten. Wegen der Seltenheit der Urteilsverkündung und der Möglichkeit einer längerfristigen Vollstreckung Wie oben erwähnt, können Knoten in der zweiten Ebene im Gegensatz zur ersten Ebene: 1. Für die Durchführung der Rechtsprechung eine hohe Vergütung erhalten. 2. Nutzen Sie zusätzliche Datenquellen, die über den vielfältigen Datenbestand der ersten Ebene hinausgehen. 3. Verlassen Sie sich auf manuelle und/oder fachmännische Inspektionen und Eingriffe, z. B. um zu identifizieren und Vergleichen Sie Fehler in Quelldaten und unterscheiden Sie zwischen einer ehrlichen Knotenweiterleitung fehlerhafte Daten und ein Knoten, der sich schlecht verhält. Wir betonen, dass der Ansatz, den wir gerade für die Auswahl von Knoten der zweiten Ebene und die Richtlinien zur Entscheidungsfindung beschrieben haben, nur einen Punkt innerhalb eines großen Spektrums darstellt Gestaltungsraum möglicher Realisierungen der zweiten Ebene. Unser Anreizmechanismus bietet völlige Flexibilität bei der Umsetzung der zweiten Ebene. Einzelne DONs können somit bilden und legen Regeln für ihre zweite Ebene fest, die den jeweiligen Anforderungen gerecht werden und Erwartungen der teilnehmenden Knoten und Benutzer. DECO und Town Crier als Entscheidungswerkzeuge: Es ist für die zweite Stufe unerlässlich in unserem Mechanismus, um zwischen gegnerischen Knoten der ersten Ebene unterscheiden zu können Erstellen Sie absichtlich falsche Berichte und ehrliche First-Tier-Knoten, die dies unbeabsichtigt tun Weitergabe von Daten, die an der Quelle falsch sind. Erst dann kann die zweite Stufe umsetzen Kürzungen, um Betrug zu verhindern, das Ziel unseres Mechanismus. DECO und Town Crier sind leistungsstarke Tools, mit denen Knoten der zweiten Ebene diese entscheidende Unterscheidung treffen können zuverlässig.Knoten der zweiten Ebene können in einigen Fällen möglicherweise direkt die verwendete Datenquelle abfragen von einem First-Tier-Knoten oder verwenden Sie ADO Abschnitt 7.1, um zu überprüfen, ob ein falscher Bericht vorliegt resultierte aus einer fehlerhaften Datenquelle. In anderen Fällen fehlen jedoch möglicherweise Knoten der zweiten Ebene Direkter Zugriff auf die Datenquelle eines First-Tier-Knotens. In solchen Fällen wäre eine korrekte Entscheidung erforderlich scheinen undurchführbar zu sein oder erfordern ein Vertrauen auf subjektives Urteilsvermögen. Vorheriger oracle Streitbeilegungssysteme haben sich auf ineffiziente, eskalierende Abstimmungsrunden verlassen, um solche Probleme anzugehen Herausforderungen. Mit DECO oder Town Crier kann ein First-Tier-Knoten jedoch korrektes Verhalten nachweisen zu Knoten der zweiten Ebene. (Einzelheiten zu den beiden Systemen finden Sie in Abschnitt 3.6.2.) Insbesondere wenn Der Knoten der zweiten Ebene identifiziert einen Knoten der ersten Ebene als einen Knoten der ersten Ebene, der einen fehlerhaften Berichtswert ˜r ausgegeben hat. Der Knoten der ersten Ebene kann DECO oder Town Crier verwenden, um fälschungssichere Beweise dafür zu generieren Knoten der zweiten Ebene, die korrekt von einer (TLS-fähigen) Quelle weitergeleitet werden vom DON als maßgeblich anerkannt. Entscheidend ist, dass der Knoten der ersten Ebene dies tun kann ohne dass Knoten der zweiten Ebene direkten Zugriff auf die Datenquelle erfordern.17 Folglich Eine korrekte Beurteilung ist in Chainlink für jede gewünschte Datenquelle möglich. 9.4.4 Falsche Berichterstattung über Versicherungen Die starke Bestechungsresistenz, die durch unseren staking-Mechanismus erreicht wird, beruht grundsätzlich darauf über gekürzte Gelder für Warner. Ohne eine finanzielle Belohnung würden die Warner dies tun keinen direkten Anreiz haben, Bestechungsgelder abzulehnen. Dies führt jedoch nicht zu gekürzten Mitteln zur Verfügung, um Benutzer zu entschädigen, die durch falsche Berichte geschädigt wurden, z. B. Benutzer, die Geld verlieren wenn falsche Preisdaten an einen smart contract weitergeleitet werden. Es wird davon ausgegangen, dass falsche Berichte kein Problem darstellen, wenn Berichte von a akzeptiert werden Vertrag erst nach einer möglichen gerichtlichen Entscheidung, d. h. einer Klage der zweiten Ebene, abschließen. Wie erklärt Um jedoch die bestmögliche Leistung zu erzielen, können Verträge stattdessen auf die oben genannten Punkte zurückgreifen Sie sind hinsichtlich des Mechanismus zur Durchsetzung einer korrekten Berichterstattung optimistisch, was bedeutet, dass sie zustimmen Berichte vor einer möglichen zweitrangigen Entscheidung. Tatsächlich solch ein optimistisches Verhalten ist in unserem Modell sicher unter der Annahme rationaler Gegner, deren Budgets das nicht überschreiten staking Auswirkungen des Mechanismus. Benutzer sind besorgt über den unwahrscheinlichen Fall eines Mechanismusfehlers, der auf Folgendes zurückzuführen ist: Beispielsweise möchten Gegner mit überwältigenden finanziellen Ressourcen möglicherweise eine zusätzliche Ebene der wirtschaftlichen Sicherheit in Form einer Falschmeldungsversicherung einsetzen. Wir wissen es Mehrere Versicherer beabsichtigen bereits, solche Smart-Contract-basierten Policen anzubieten für Chainlink-gesicherte Protokolle in naher Zukunft, unter anderem durch innovative Mechanismen wie DAOs, z. B. [7]. Das Vorhandensein eines Leistungsverlaufs für Chainlink Knoten und andere Daten über Knoten, wie z. B. deren Einsatzbeträge, bieten eine außergewöhnlich solide Grundlage für versicherungsmathematische Risikobewertungen und ermöglichen die Preisgestaltung von Policen auf eine Weise, die für Versicherungsnehmer kostengünstig und für Versicherer dennoch nachhaltig ist. 17Mit Town Crier ist es darüber hinaus für First-Tier-Knoten möglich, Attestierungen lokal zu generieren der Korrektheit der von ihnen ausgegebenen Berichte und stellen diese Bescheinigungen den Knoten der zweiten Ebene auf einem zur Verfügung nach Bedarf.Grundlegende Formen der Falschmeldungsversicherung können vertrauenswürdig und vertrauenswürdig umgesetzt werden effiziente Weise mit smart contracts. Als einfaches Beispiel eine parametrische Versicherung Vertrags-SCins können Versicherungsnehmer automatisch entschädigen, wenn unser Anreizmechanismus vorhanden ist Die zweite Ebene identifiziert einen Fehler in einem Bericht, der in der ersten Ebene erstellt wurde. Ein Benutzer U, der eine Versicherungspolice erwerben möchte, z. B. der Ersteller eines Ziels Vertrags-SC, kann bei einem dezentralen Versicherer einen Antrag auf eine Versicherungssumme stellen $M auf dem Vertrag. Mit der Genehmigung von U kann der Versicherer eine laufende (z. B. monatliche) Prämie von $P in SCins. Während U die Prämie zahlt, bleibt ihre Police aktiv. Wenn in SC ein Meldefehler auftritt, wird als Ergebnis ein Paar (r1, r2) ausgegeben. von widersprüchlichen Berichten für SC, wobei r1 von der ersten Ebene in unserem Mechanismus signiert wird und r2, der entsprechende korrigierte Bericht, wird von der zweiten Ebene unterzeichnet. Wenn das U einrichtet Wenn Sie ein solches gültiges Paar (r1, r2) an SCins senden, zahlt der Vertrag ihr automatisch $M, vorausgesetzt Ihre Prämienzahlungen sind auf dem neuesten Stand. 9.5 Einrunde Variante Das im vorherigen Unterabschnitt beschriebene Protokoll erfordert, dass das Komitee der zweiten Ebene n Runden wartet, um festzustellen, ob ein Wachhund einen Alarm ausgelöst hat. Dies Die Anforderung gilt auch im optimistischen Fall, d. h. wenn die erste Stufe funktioniert richtig. Für Benutzer, die nicht bereit sind, Berichte optimistisch, d. h. vor dem Potenzial, anzunehmen Bei einem Urteil wäre die mit diesem Ansatz verbundene Verzögerung undurchführbar. Aus diesem Grund erforschen wir auch alternative Protokolle, die nur eines erfordern rund. Bei diesem Ansatz übermitteln alle oracle-Knoten geheime Bits, die angeben, ob oder nicht Sie möchten eine Warnung auslösen. Das Gremium der zweiten Ebene prüft diese Werte dann Prioritätsreihenfolge. Um eine grobe Skizze zu geben, könnte ein solches Schema Folgendes umfassen Schritte: 1. Watchdog-Bit-Übermittlung: Jeder Knoten-Oi-Geheimnis teilt einen Ein-Bit-Watchdog-Wert wi ∈{keine Warnung, Warnung} unter Knoten in der zweiten Ebene für jeden von ihm generierten Bericht. 2. Anonyme Tipps: Jeder oracle-Knoten kann in derselben Runde, in der Watchdog-Bits übermittelt werden, einen anonymen Tipp α an das Komitee der zweiten Ebene senden. Dieser Tipp α ist eine Meldung, die angibt, dass für den aktuellen Bericht eine Warnung ausgelöst wurde. 3. Überprüfung des Watchdog-Bits: Das Komitee der zweiten Ebene enthüllt den Watchdog der Knoten oracle Bits in Prioritätsreihenfolge. Beachten Sie, dass Knoten keine Alarm-Watchdog-Bits senden dürfen, wenn sie nicht alarmieren. Andernfalls werden bei der Verkehrsanalyse die Bits aller Knoten angezeigt. Das Protokoll zeigt die „Kein“-Warnung an Watchdog-Bits von Knoten mit höherer Priorität als der alarmierende Watchdog mit der höchsten Priorität. Beachten Sie, dass das, was offenbart wird, mit dem unseres n-Runden-Protokolls identisch ist. Auch die Belohnungen werden identisch mit diesem Schema verteilt, d. h. mit dem ersten identifizierten Wachhund erhält die gekürzten Einlagen von Knoten, die falsche Meldungen eingereicht haben.Die Verwendung anonymer Hinweise ermöglicht es dem Ausschuss der zweiten Ebene, in Fällen, in denen keine Warnung ausgelöst wurde, nicht interaktiv zu bleiben, wodurch die Komplexität der Kommunikation verringert wird im allgemeinen Fall. Beachten Sie, dass jeder Wachhund, der eine Warnung auslöst, einen wirtschaftlichen Anreiz hat, einen anonymen Hinweis abzugeben: Wenn kein Hinweis abgegeben wird, wird niemandem eine Belohnung gezahlt Knoten. Um sicherzustellen, dass der Absender Oi eines anonymen Hinweises nicht identifiziert werden kann Anhand von Netzwerkdaten kann der anonyme Tipp über einen anonymen Angreifer gesendet werden Kanal, z. B. über Tor, oder praktischer, Proxy über einen Cloud-Dienstanbieter. Zu Authentifizieren Sie, dass die Spitze von O stammt. Oi kann α mithilfe einer Ringsignatur signieren [39, 192]. Um nicht zuordenbare Denial-of-Service-Angriffe eines böswilligen oracle-Knotens gegen das Second-Tier-Komitee zu verhindern, kann α alternativ eine anonyme Anmeldeinformation mit sein widerrufliche Anonymität [73]. Dieses Protokoll ist zwar praktisch realisierbar, weist jedoch einen relativ hohen technischen Aufwand auf Anforderungen (die wir nach Möglichkeiten suchen, sie zu reduzieren). First-Tier-Knoten, zum Beispiel, muss direkt mit Knoten der zweiten Ebene kommunizieren und erfordert die Wartung eines Verzeichnisses. Der Bedarf an anonymen Kanälen und Ringsignaturen erhöht den technischen Aufwand Komplexität des Schemas. Abschließend wird kurz auf ein besonderes Vertrauenserfordernis eingegangen in der Anmerkung unten. Wir erforschen daher auch einfachere Konzepte, die dennoch Erfolge erzielen superlineare staking-Auswirkung, aber vielleicht weniger als quadratisch, bei der ein Bestecher beispielsweise asymptotisch Ressourcen von mindestens $n log n benötigt. Einige der folgenden Schemata Überlegungen beinhalten die zufällige Auswahl einer strengen Teilmenge von Knoten, die als Watchdogs fungieren sollen. In diesem Fall wird eine mögliche Bestechung zu einem besonders wirkungsvollen Angriff. Bemerkung: Die Sicherheit dieses einrundigen staking-Mechanismus erfordert Untapable Kanäle zwischen oracle und Knoten der zweiten Ebene – eine Standardanforderung in zwangsresistenten Systemen, z. B. Abstimmungen [82, 138], und in der Praxis eine vernünftige Anforderung. Darüber hinaus kann jedoch ein Knoten-Oi entstehen, der mit einem Bestechungsgelder kooperieren möchte seine geheimen Anteile auf eine Art und Weise weitergeben, die dem Bestechungsgelder zeigt, dass er eine bestimmte Information verschlüsselt hat Wert. Wenn Oi beispielsweise nicht weiß, welche Knoten der Bestechungsgelder kontrolliert, kann Oi dies tun Übermittlung von Aktien mit dem Wert 0 an alle Ausschussmitglieder. Der Bestecher kann dann Oi's überprüfen Compliance wahrscheinlich. Um dieses Problem in jedem Einzelrundenprotokoll zu vermeiden, haben wir erfordern, dass Oi die Identität mindestens eines ehrlichen Knotens der zweiten Ebene kennt. Mit einem interaktiven Protokoll, bei dem jeder Knoten der zweiten Ebene eine Randomisierung hinzufügt Faktor zu Aktien, das Beste, was der Bestechungsgelder tun kann, ist, die Auswahl eines Zufalls durch Oi zu erzwingen Watchdog-Bit. 9.6 Implizites Anreiz-Framework (IIF) FFO ist eine Form des impliziten Anreizes für korrektes Verhalten im Chainlink-Netzwerk. Es Funktionen wie explizite Anteile, d. h. Einlagen, indem sie zur Durchsetzung der wirtschaftlichen Sicherheit beitragen das Netzwerk. Mit anderen Worten: FFO sollte als Teil der (effektiven) Einlage berücksichtigt werden $d eines Knotens im Netzwerk.Die Frage ist: Wie messen wir den FFO und andere Formen impliziter Anreize? innerhalb des Netzwerks Chainlink? Das Implicit-Incentive Framework (IIF) besteht aus einer Reihe von Prinzipien und Techniken, die wir zu diesem Zweck entwickeln wollen. Blockchain-Systeme bieten viele Formen beispielloser Transparenz und die äußerst vertrauenswürdigen Aufzeichnungen von Node Die Leistung, die sie erbringen, ist ein Sprungbrett für unsere Vision, wie das IIF funktionieren wird. Hier skizzieren wir ganz kurz Ideen zu Schlüsselelementen des IIF. Der IIF selbst besteht aus einer Reihe von Faktoren, die wir bei der Bewertung als wichtig erachten implizite Anreize sowie Mechanismen zur Veröffentlichung relevanter Daten in einer hochsicheren Form für die Nutzung durch Analysealgorithmen. Verschiedene Chainlink-Benutzer können Sie möchten den IIF auf unterschiedliche Weise nutzen, z. B. um verschiedenen Faktoren eine unterschiedliche Gewichtung zu geben. Wir erwarten, dass in der Community Analysedienste entstehen, die Benutzern bei der Anwendung des IIF helfen entsprechend ihren individuellen Risikobewertungspräferenzen, und unser Ziel ist es, dies zu erleichtern solche Dienste, indem sie ihren Zugang zu hochsicheren und zeitnahen unterstützenden Daten sicherstellen, wie wir weiter unten diskutieren (Abschnitt 9.6.4). 9.6.1 Zukünftige Gebührenmöglichkeit Knoten nehmen am Chainlink-Ökosystem teil, um einen Anteil an den Gebühren zu verdienen, die die Netzwerke für die verschiedenen Dienste zahlen, die wir in diesem Dokument beschrieben haben gewöhnliche Datenfeeds für erweiterte Dienste wie dezentrale Identität, faire Sequenzierung, und vertraulichkeitswahrend DeFi. Die Gebühren im Netzwerk Chainlink decken die Kosten der Knotenbetreiber, z. B. für den Betrieb von Servern, den Erwerb erforderlicher Datenlizenzen und die Wartung Ein globales Personal, um eine hohe Verfügbarkeit zu gewährleisten. FFO bezeichnet die Servicegebühren, abzüglich der Kosten, dass ein Knoten in Zukunft gewinnen oder verlieren kann, wenn er fehlerhaftes Verhalten zeigt. FFO ist eine Form des Anteils, der zur Sicherung des Netzwerks beiträgt. Ein hilfreiches Merkmal von FFO ist die Tatsache, dass On-Chain-Daten (ergänzt durch Off-Chain-Daten). Daten) erstellen einen hochvertrauenswürdigen Datensatz des Verlaufs eines Knotens und ermöglichen so die Berechnung des FFO auf transparente, empirisch fundierte Weise. Ein einfaches Maß erster Ordnung für den FFO kann aus dem durchschnittlichen Nettoumsatz eines Unternehmens abgeleitet werden Knoten über einen bestimmten Zeitraum (d. h. Bruttoeinnahmen minus Betriebskosten). FFO kann dann beispielsweise als Nettobarwert [114] des kumulierten zukünftigen Nettoumsatzes berechnet werden, mit anderen Worten, der zeitdiskontierte Wert aller zukünftigen Einnahmen. Knoteneinnahmen können jedoch volatil sein, wie beispielsweise in Abb. 17 dargestellt. Noch wichtiger ist, dass die Knoteneinnahmen möglicherweise keiner stationären Verteilung folgen im Laufe der Zeit. Zu den weiteren Faktoren, die wir bei der FFO-Schätzung untersuchen möchten, gehören daher: • Leistungsverlauf: Der Leistungsverlauf eines Betreibers – einschließlich der Richtigkeit und Aktualität seiner Berichte sowie seiner Betriebszeit – liefert ein Ziel Prüfstein für Benutzer zur Bewertung seiner Zuverlässigkeit. Der Leistungsverlauf wird somit stellen einen entscheidenden Faktor bei der Auswahl von oracle-Knoten durch Benutzer dar (oder, mit dem Aufkommen). von DONs, ihre Auswahl von DONs). Eine starke Leistungshistorie ist wahrscheinlich korrelieren mit hohen laufenden Umsätzen.18 18Eine wichtige Forschungsfrage, der wir uns widmen wollen, ist die Erkennung gefälschter Leistungsmengen.Abbildung 17: Einnahmen, die Chainlink-Knoten in einem einzelnen Daten-Feed (ETH-USD) erzielt haben eine repräsentative Woche im März 2021. • Datenzugriff: Während oracles möglicherweise viele Formen von Daten von offenen APIs erhalten, Bestimmte Arten von Daten oder bestimmte hochwertige Quellen sind möglicherweise nur auf a verfügbar auf Abonnementbasis oder durch vertragliche Vereinbarungen. Privilegierter Zugriff auf bestimmte Datenquellen können bei der Schaffung einer stabilen Einnahmequelle eine Rolle spielen. • DON-Teilnahme: Mit der Einführung von DONs werden Gemeinschaften von Knoten entstehen zusammen, um bestimmte Dienstleistungen zu erbringen. Wir gehen davon aus, dass viele DONs enthalten sein werden Betreiber auf selektiver Basis, die Beteiligung an seriösen DONs als privilegierte Marktposition, die dazu beiträgt, eine konsistente Einnahmequelle zu gewährleisten. • Plattformübergreifende Aktivität: Einige Knotenbetreiber verfügen möglicherweise über gut etablierte Präsenzen und Leistungsnachweise in anderen Kontexten, z. B. als PoS validators oder Datenanbieter in Nicht-blockchain-Kontexten. Ihre Leistung in diesen anderen Systemen (sofern Daten darüber in vertrauenswürdiger Form verfügbar sind) kann in die Bewertung einfließen ihrer Leistungsgeschichte. Ebenso fehlerhaftes Verhalten im Netzwerk Chainlink kann den Umsatz in diesen anderen Systemen gefährden, indem es Benutzer vertreibt, d. h. den FFO kann sich plattformübergreifend erstrecken. 9.6.2 Spekulativer FFO Knotenbetreiber beteiligen sich nicht nur am Chainlink-Netzwerk, um damit Einnahmen zu erzielen sondern sich zu schaffen und zu positionieren, um neue Möglichkeiten zur Führung von Arbeitsplätzen zu nutzen. Mit anderen Worten, auch die Ausgaben von oracle Knoten im Netzwerk eine positive Aussage über die Zukunft von DeFi und anderen Smart-Contract-Anwendungen Domänen sowie neue Nicht-blockchain-Anwendungen von oracle-Netzwerken. Knotenbetreiber verdienen heute die Gebühren, die in bestehenden Chainlink-Netzwerken verfügbar sind, und zwar gleichzeitig Diese ähneln im Großen und Ganzen gefälschten Bewertungen auf Internetseiten, mit der Ausnahme, dass das Problem dort einfacher ist oracle-Einstellung, da wir eine eindeutige Aufzeichnung darüber haben, ob die Waren, d. h. Berichte, bestellt wurden und geliefert – im Gegensatz zu beispielsweise physischen Waren, die in Online-Shops bestellt werden. Anders ausgedrückt, im oracle In dieser Einstellung kann die Leistung validiert werden, auch wenn dies durch die Wahrhaftigkeit des Kunden nicht möglich ist.Bauen Sie einen Ruf, eine Leistungshistorie und ein operatives Fachwissen auf, das Ihnen eine gute Position verschafft sie vorteilhaft, um Gebühren zu verdienen, die in zukünftigen Netzwerken verfügbar sind (natürlich abhängig von auf ehrliches Verhalten). Die Knoten, die heute im Ökosystem Chainlink aktiv sind, werden dabei berücksichtigt Sinn haben gegenüber Neueinsteigern einen Vorteil beim Verdienen der Gebühren als zusätzliche Chainlink Dienste verfügbar werden. Dieser Vorteil gilt sowohl für neue Betreiber als auch für Technologieunternehmen mit etabliertem Ruf; zum Beispiel T-Systems, ein Traditionsunternehmen Technologieanbieter (Tochtergesellschaft der Deutschen Telekom) und Kraken, ein großes Zentralunternehmen Austausch, haben frühe Präsenzen im Chainlink-Ökosystem etabliert [28, 143]. Eine solche Teilnahme von oracle-Knoten an zukünftigen Gelegenheiten kann als solche betrachtet werden als eine Art spekulativer FFO und stellt somit eine Form der Beteiligung am Chainlink dar. Netzwerk. 9.6.3 Externer Ruf Das IIF, wie wir es beschrieben haben, kann in einem Netzwerk unter strenger Pseudonymisierung operieren Betreiber, d. h. ohne Offenlegung der beteiligten Personen oder realen Entitäten. Ein potenziell wichtiger Faktor für die Anbieterauswahl durch Nutzer ist jedoch externer Natur Ruf. Mit externer Reputation meinen wir die Wahrnehmung von Vertrauenswürdigkeit, die mit realen Identitäten und nicht mit Pseudonymen verbunden ist. Reputationsrisiko verbunden mit Identitäten in der realen Welt können als eine Form impliziter Anreize angesehen werden. Wir betrachten den Ruf durch die Linse des IIF, also im kryptoökonomischen Sinne, als Mittel zur Etablierung plattformübergreifende Aktivitäten, die in die FFO-Schätzungen einbezogen werden können. Der Vorteil der Verwendung der externen Reputation als Faktor bei der FFO-Schätzung im Gegensatz dazu Die pseudonyme Verknüpfung besteht darin, dass die externe Reputation die Leistung nicht nur mit einer verknüpft bestehende Aktivitäten des Betreibers, aber auch auf zukünftige. Wenn zum Beispiel ein schlechter Ruf Wenn etwas an eine einzelne Person gebunden ist, kann es die künftigen Unternehmungen dieser Person gefährden. Anders ausgedrückt: Die externe Reputation kann einen größeren Teil des FFO erfassen als die pseudonyme Reputation Leistungsnachweise, wie die Auswirkung von Fehlverhalten auf eine Person ausgeübt oder festgestellt wird Einem Unternehmen zu entkommen ist schwerer als bei einer pseudonymen Operation. Chainlink ist mit dezentralen Identitätstechnologien (Abschnitt 4.3) kompatibel kann die Nutzung der externen Reputation im IIF unterstützen. Solche Technologien kann die Richtigkeit der von den Betreibern behaupteten realen Welt validieren und dadurch sicherstellen Identitäten.19 9.6.4 Öffnen Sie IIF Analytics Das IIF zielt, wie bereits erwähnt, darauf ab, zuverlässige Open-Source-Daten und -Tools bereitzustellen Implizite Anreizanalyse. Ziel ist es, Anbieter innerhalb der Community zu ermöglichen Entwicklung von Analysen, die auf die Risikobewertungsanforderungen verschiedener Teile des Unternehmens zugeschnitten sind Chainlink Benutzerbasis. 19Dezentrale Identitätsnachweise können bei Bedarf auch Pseudonyme mit validierten ausschmücken ergänzende Informationen. Beispielsweise könnte ein Knotenbetreiber grundsätzlich solche Anmeldeinformationen verwenden beweisen, dass es sich um ein Fortune-500-Unternehmen handelt, ohne zu verraten, um welches Unternehmen es sich handelt.Eine beträchtliche Menge historischer Daten zum Umsatz und zur Leistung der Knoten befindet sich in einer äußerst vertrauenswürdigen, unveränderlichen Form in der Kette. Unser Ziel ist es jedoch, das bereitzustellen möglichst umfassende Daten, einschließlich Daten zu Verhaltensweisen, die nur aus dem Off sichtbar sind B. Off-Chain Reporting (OCR) oder DON-Aktivität. Solche Daten können möglicherweise voluminös sein. Der beste Weg, es aufzubewahren und seine Unversehrtheit zu gewährleisten, d. h. es zu schützen Wir gehen davon aus, dass die Manipulation mit Hilfe von DONs und unter Verwendung der besprochenen Techniken erfolgen wird in Abschnitt 3.3. Einige Anreize eignen sich für direkte Formen der Messung, z. B. staking Einlagen und Basis-FFO. Andere, wie spekulativer FFO und Reputation, sind schwieriger zu ermitteln Messen Sie auf objektive Weise, aber wir glauben, dass unterstützende Datenformen, einschließlich historisches Wachstum des Chainlink-Ökosystems, Social-Media-Reputationskennzahlen usw., kann IIF-Analysemodelle auch für diese schwieriger zu quantifizierenden Elemente unterstützen. Wir können uns vorstellen, dass dedizierte DONs speziell zur Überwachung, Validierung und Überwachung entstehen Zeichnen Sie Daten auf, die sich auf Off-Chain-Leistungsaufzeichnungen von Knoten beziehen, sowie andere Daten im IIF verwendet werden, wie z. B. validierte Identitätsinformationen. Diese DONs können einheitliche, äußerst vertrauenswürdige IIF-Daten für alle Analyseanbieter bereitstellen, die die Chainlink-Community bedienen. Sie stellen außerdem einen goldenen Datensatz zur Verfügung, der die Ansprüche von Analyseanbietern bestätigt unabhängig von der Community überprüfbar. 9.7 Alles zusammen: Anreize für Knotenbetreiber Zusammenfassung unserer obigen Diskussionen zu expliziten und impliziten Anreizen für Knotenbetreiber bietet einen ganzheitlichen Überblick über die Art und Weise, wie Knotenbetreiber teilnehmen und davon profitieren das Netzwerk Chainlink. Als konzeptioneller Leitfaden können wir das Gesamtvermögen eines bestimmten Chainlink ausdrücken. Knotenoperator $S in einer groben, stilisierten Form als: \(S ≈\)D + \(F + \)FS + $R, wo: • $D ist die Summe aller explizit hinterlegten Einsätze in allen Netzwerken, in denen der Betreiber beteiligt sich; • $F ist der Nettogegenwartswert der Summe aller FFO in allen Netzwerken in an denen der Betreiber teilnimmt; • $FS ist der Nettobarwert des spekulativen FFO des Betreibers; und • $R ist der Reputationswert des Betreibers außerhalb des Chainlink-Ökosystems Dies könnte durch festgestelltes Fehlverhalten in seinen oracle-Knoten gefährdet sein. Obwohl diese grobe Gleichheit größtenteils konzeptionell ist, zeigt sie hilfreich, dass es eine Vielzahl wirtschaftlicher Faktoren gibt, die eine hochzuverlässige Leistung von Chainlink-Knoten begünstigen. Alle diese Faktoren außer $D sind in den heutigen Chainlink-Netzwerken vorhanden.9.8 Der positive Kreislauf der wirtschaftlichen Sicherheit Die Kombination aus superlinearer staking Wirkung mit der Darstellung von Gebührenzahlungen da zukünftige Gebührenchancen (FFO) im IIF zu dem führen können, was wir den positiven Kreislauf nennen der wirtschaftlichen Sicherheit in einem oracle Netzwerk. Dies kann als eine Art Ökonomie angesehen werden der Skala. Da der von einem bestimmten Netzwerk gesicherte Gesamtbetrag steigt, steigt die Menge an Der zusätzliche Einsatz, der erforderlich ist, um einen festen Betrag an wirtschaftlicher Sicherheit hinzuzufügen, nimmt ebenfalls ab die durchschnittlichen Kosten pro Benutzer. Daher ist der Beitritt für einen Benutzer hinsichtlich der Gebühren günstiger eines bereits bestehenden Netzwerks, als die gleiche Steigerung der Netzwerkökonomie zu erreichen Sicherheit durch die Schaffung eines neuen Netzwerks. Wichtig ist, dass die Zahl der neuen Benutzer sinkt die Kosten des Dienstes für alle vorherigen Benutzer dieses Netzwerks. Bei einer bestimmten Gebührenstruktur (z. B. einer bestimmten Rendite auf den eingesetzten Betrag) Wenn die Gesamtgebühren, die ein Netzwerk einnimmt, steigen, ist dies ein Anreiz für den Fluss zusätzlicher Gebühren Beteiligung am Netzwerk, um es mit einer höheren Rate zu sichern. Konkret, wenn der Gesamteinsatz Ein einzelner Knoten kann im System eine Obergrenze einhalten, wenn dann neue Gebührenzahlungen erfolgen Wenn Sie in das System eintreten und dessen FFO erhöhen, erhöht sich die Anzahl der Knoten n. Danke an die Superlineare staking Auswirkungen unseres Anreizsystemdesigns, die wirtschaftliche Sicherheit von das System wird schneller ansteigen als n, z. B. als n2 in dem Mechanismus, den wir in Abschnitt 9.4 skizzieren. Daraus ergeben sich die durchschnittlichen Kosten für die wirtschaftliche Sicherheit – d. h. die Höhe des Beitrags ein Dollar an wirtschaftlicher Sicherheit – wird sinken. Das Netzwerk kann daher seinen Nutzern Gebühren berechnen niedrigere Gebühren. Unter der Annahme, dass die Nachfrage nach oracle-Diensten elastisch ist (siehe z. B. [31] für eine kurze Beschreibung). Erklärung), wird die Nachfrage steigen und zusätzliche Gebühren und FFO generieren. Wir veranschaulichen diesen Punkt anhand des folgenden Beispiels. Beispiel 5. Seit der wirtschaftlichen Sicherheit eines oracle-Netzwerks mit unserem Anreiz Das Schema ist \(dn2 for stake \)dn, die wirtschaftliche Sicherheit, die durch einen Dollar Einsatz erzielt wird ist n und damit die durchschnittlichen Kosten pro Dollar der wirtschaftlichen Sicherheit – also die Höhe des Einsatzes Der Beitrag zu einem Dollar wirtschaftlicher Sicherheit beträgt 1/n. Stellen Sie sich ein Netzwerk vor, in dem die wirtschaftlichen Anreize ausschließlich aus gedeckelten FFO bestehen bei \(d ≤\)10K pro Knoten. Angenommen, das Netzwerk hat n = 3 Knoten. Dann die durchschnittlichen Kosten pro Dollar wirtschaftlicher Sicherheit beträgt etwa 0,33 US-Dollar. Angenommen, der Gesamt-FFO des Netzwerks steigt über \(30K (e.g., to \)31K). Gegeben Durch die Obergrenze des FFO pro Knoten wächst das Netzwerk auf (mindestens) n = 4. Nun die durchschnittlichen Kosten pro Dollar an wirtschaftlicher Sicherheit sinkt auf etwa 0,25 Dollar. Wir veranschaulichen den gesamten positiven Kreislauf der wirtschaftlichen Sicherheit in oracle-Netzwerken schematisch in Abb. 18. Wir betonen, dass der positive Kreislauf der wirtschaftlichen Sicherheit aus der Wirkung resultiert von Nutzern, die ihre Gebühren bündeln. Es ist ihr kollektiver FFO, der sich zugunsten größerer Unternehmen auswirkt Netzwerkgrößen und damit größere kollektive Sicherheit. Wir stellen auch fest, dass der tugendhafte Kreislauf Die wirtschaftliche Sicherheit trägt dazu bei, dass DONs finanzielle Nachhaltigkeit erreichen. Einmal erstellt, DONs, die auf Benutzerbedürfnisse eingehen, sollten bis zu diesem Punkt und darüber hinaus wachsen Die Einnahmen aus Gebühren übersteigen die Betriebskosten für oracle-Knoten.

Abbildung 18: Schematische Darstellung des positiven Zyklus von Chainlink staking. Eine Erhöhung der Nutzungsgebühr Zahlungen an ein oracle Netzwerk 1⃝führen dazu, dass es wächst, was zu einem Wachstum seiner Wirtschaft führt Sicherheit 2⃝. Dieses superlineare Wachstum ermöglicht Skaleneffekte in Chainlink Netzwerken 3⃝. Konkret bedeutet es eine Reduzierung der durchschnittlichen Kosten wirtschaftlicher Sicherheit, d. h. die wirtschaftliche Sicherheit pro Dollar, die sich aus Gebührenzahlungen oder anderen Beteiligungsquellen ergibt erhöht sich. Niedrigere Kosten, die an die Benutzer weitergegeben werden, stimulieren die erhöhte Nachfrage nach oracle Dienstleistungen 4⃝. 9.9 Zusätzliche Faktoren, die das Netzwerkwachstum vorantreiben Da das Chainlink-Ökosystem weiter wächst, glauben wir, dass es an Attraktivität gewinnt für die Nutzer und die Bedeutung als Infrastruktur für die blockchain Wirtschaft wird zunehmen. Der von oracle-Netzwerken bereitgestellte Wert ist superlinear, was bedeutet, dass er schneller wächstals die Größe der Netzwerke selbst. Dieser Wertzuwachs resultiert aus beidem Skaleneffekte – höhere Kosteneffizienz pro Benutzer bei steigendem Servicevolumen – und Netzwerkeffekte – eine Steigerung des Netzwerknutzens, da Benutzer DONs weiter verbreiten. Da bestehende smart contracts weiterhin einen höheren Wert haben, sind sie gesichert und völlig neu Insgesamt werden smart contract Anwendungen durch dezentralere Dienste ermöglicht Die Nutzung und die an DONs gezahlten Gesamtgebühren sollten steigen. Steigende Gebührenpools in wiederum in die Mittel und Anreize für die Schaffung noch stärker dezentraler Dienste umsetzen, Daraus ergibt sich ein positiver Kreislauf. Dieser positive Kreislauf löst ein kritisches Henne-Ei-Problem Problem im hybriden smart contract-Ökosystem: Innovative smart contract-Funktionen erfordern oft dezentrale Dienste, die noch nicht existieren (z. B. oft neue DeFi Märkte). (Sie benötigen neue Datenfeeds), benötigen jedoch eine ausreichende wirtschaftliche Nachfrage, um zu existieren. Die Zusammenlegung der Gebühren verschiedener smart contracts für bestehende DONs wird ein Signal für die Nachfrage nach zusätzliche dezentrale Dienste von einer wachsenden Benutzerbasis, was zu deren Schaffung führte durch DONs und eine fortlaufende Ermöglichung neuer und vielfältiger Hybrid-smart contracts. Zusammenfassend glauben wir, dass das Wachstum der Netzwerksicherheit von Tugendhaftigkeit vorangetrieben wird Zyklen im Chainlink staking Mechanismus veranschaulichen größere Wachstumsmuster, die Das Netzwerk Chainlink kann dazu beitragen, eine dezentrale On-Chain-Wirtschaft zu schaffen Dienstleistungen.

Abschluss

In diesem Dokument haben wir eine Vision für die Entwicklung von Chainlink dargelegt. Das Hauptthema In dieser Vision liegt die Fähigkeit von oracle Networks, ein viel breiteres Spektrum an Dienstleistungen anzubieten smart contracts als die reine Datenlieferung. Chainlink nutzt DONs als Grundlage für die dezentralen Dienste der Zukunft und zielt darauf ab, leistungsstarke, vertraulichere oracle-Funktionen bereitzustellen. Seine oracle-Netzwerke bieten eine starke Vertrauensminimierung durch eine Kombination prinzipieller kryptoökonomischer Mechanismen wie staking und Sorgfältig konzipierte Leitplanken und Durchsetzung des Service-Levels auf vertrauenden Hauptketten. DONs wird auch dazu beitragen, dass Layer-2-Systeme flexible, faire Bestellrichtlinien für Transaktionen durchsetzen und die Gaskosten für über Mempool weitergeleitete Transaktionen senken. Zusammengenommen, Diese Fähigkeiten zielen alle auf einen sicheren und funktionsreichen Hybrid-Smart ab Verträge. Die Flexibilität von DONs wird die bestehenden Chainlink-Dienste verbessern und Anlass geben viele zusätzliche smart contract Funktionen und Anwendungen. Darunter sind nahtlos Verbindung zu einer Vielzahl von Off-Chain-Systemen, dezentrale Identitätserstellung von Vorhandene Daten und vorrangige Kanäle, um die rechtzeitige Bereitstellung infrastrukturkritischer Daten sicherzustellen Transaktionen und vertraulichkeitswahrende DeFi Instrumente. Die Vision, die wir hier dargelegt haben, ist ehrgeizig. Kurzfristig wollen wir stärken Hybridverträge, um Ziele zu erreichen, die heute außerhalb der Reichweite von smart contracts liegen Langfristig streben wir die Realisierung eines dezentralen Metalayers an. Zum Glück können wir zeichnen über neue Tools und Ideen – von Konsensalgorithmen bis hin zu wissensfreien Beweisen Systeme – die die Community als Ergebnis der sich schnell entwickelnden Forschung entwickelt.

Ebenso gehen wir davon aus, dass wir als Reaktion darauf der Umsetzung der Ideen in diesem Papier Priorität einräumen werden auf die Bedürfnisse der Benutzergemeinschaft von Chainlink zugeschnitten. Wir freuen uns auf die nächste Etappe in unserem Bestreben, smart contracts durch universelle Konnektivität zu stärken und zu etablieren dezentrale Technologien als Rückgrat der nächsten Finanzgeneration der Welt und Rechtssysteme. Danksagungen Vielen Dank an Julian Alterini und Shawn Lee für die Darstellung der Zahlen in diesem Artikel.