Bisher besteht der Mythos des Wohlergehens in der Währungskreis-/Blockchain-Industrie fort, und der nächste wichtige Bereich der „Schaffung von Wohlstand“ konzentriert sich auf die „Spielspur“. Das XAI-Projekt veranstaltet ein Odyssey-Event. Wenn Sie interessiert sind, nehmen Sie bitte an diesem Artikel von mir teil: XAI Game Public Chain Odyssey Event Zero-Cost Beginner’s Guide
In diesem Artikel werde ich Ihnen eine detaillierte Erklärung des Sentry-Knotens der öffentlichen Kette des XAI-Spiels geben! Dieser Artikel ist relativ technisch. Wenn Sie also daran interessiert sind, Geld zu verdienen, müssen Sie ihn sorgfältig lesen. Denn nur wenn Sie die „Logik“ selbst verstehen und Ihre Kognition verbessern, haben Sie die Möglichkeit, Geld zu verdienen!
Wenn Sie den Sentry-Knoten direkt sehen möchten, lesen Sie den ersten Teil direkt, ohne ihn später zu lesen. Wenn Sie eine logische geschlossene Schleife wünschen, müssen Sie den zweiten, dritten und vierten Teil lesen!
Was ich hervorheben möchte ist, dass Xai direkten technischen Support von Offchain Labs erhält. Diese Art der Unterstützung ist für andere Orbit-Ketten undenkbar! und ist eine Schlüsselkomponente von Xais strategischem Spielplan innerhalb des Arbitrum-Ökosystems.
Teil 1: Erklärung des Sentry-Knotens
Der Sentry-Knoten ist ein Beobachtungsknoten, der das Xai-Rollup-Protokoll überwacht. Wenn ein fehlerhafter Block vorgeschlagen wird, gibt er einen Alarm aus (auf welche Weise auch immer der Betreiber wählt), damit andere eingreifen können. Der Zweck des Sentinel-Knotens besteht darin, das Dilemma des Prüfers zu lösen (Einzelheiten zum Dilemma des Prüfers finden Sie in Teil IV).
Klicken Sie hier, um das Werbevideo anzusehen:
Führen Sie Xai-Knoten aus und erhalten Sie Xai-Tokens mit einem Klick!
Sentinel-Knoten können auf Laptops, Desktops oder sogar Cloud-Instanzen von Community-Mitgliedern ausgeführt werden. Solange der Knoten läuft, gibt es einen Wahrscheinlichkeitsalgorithmus, der bestimmt, ob der Knotenbetreiber mit esXai-Tokens vom Netzwerk belohnt wird. Indem Sie Xai einsetzen, erhöhen Sie die Wahrscheinlichkeit des Algorithmus. Wenn Sie esXai nicht kennen, nehmen Sie bitte an meinem Artikel zum Thema teil: Interpretation der „Token Economy“ des XAI-Projekts
1. Funktionsprinzip des Sentinel-Knotens
Das Attention Challenge v2-Protokoll umfasst mehrere Teilnehmer, darunter die Xai-Kette, eine übergeordnete Kette (Arbitrum One), einen vertrauenswürdigen Herausforderer, Xai-Sentinels und ihre Lizenzschlüssel sowie einen Referee-(Schiedsrichter-)Vertrag. Der Herausforderer erstellt ein BLS-Schlüsselpaar, registriert den öffentlichen Schlüssel für den Schiedsrichtervertrag und unterzeichnet die vom Validator aufgestellten Ansprüche im Xai-Rollup-Protokoll auf Arbitrum One. Diese Unterschriften werden durch den Schiedsrichtervertrag überprüft und als mit dem Anspruch verbundene Anfechtungen erfasst.
Xai Sentinels können sich durch den Kauf eines Sentinel-Lizenzschlüssels für den Schiedsrichtervertrag registrieren, um berechtigt zu sein, Stellungnahmen zu Ansprüchen zu veröffentlichen. Sie erhalten die Statuswurzel der richtigen Anweisung, die der Nachfolger der ausstellenden Anweisung sein wird. Wenn eine bestimmte Bedingung erfüllt ist, geben sie unter Berufung auf den Schiedsrichtervertrag eine Stellungnahme zu der Aussage ab. Wenn eine Folgeabrechnung erstellt und bestätigt wird und Sentinel die korrekte Abrechnung ausstellt, kontaktiert Sentinel den Schiedsrichtervertrag, um eine Einlösungstransaktion durchzuführen. Der Schiedsrichter prüft mehrere Bedingungen, bevor er die Belohnung an den Sentinel auszahlt.
Dieses Protokoll stellt sicher, dass jeder Anspruch die Posteingangsnachrichten, die zum Zeitpunkt der Erstellung des Vorgängeranspruchs vorhanden waren, vollständig verbrauchen muss. Dies bedeutet, dass nach der Erstellung eines Anspruchs die Zustandswurzeln seiner korrekten nachfolgenden Ansprüche vollständig bestimmt sind und von jedem Knoten berechnet werden können. Dies ermutigt jeden Sentinel, die korrekte nächste Zustandswurzel zu bestimmen. Die Belohnung des Sentinels wird durch die Statusberechtigungs-ID des Sentinels, den nachfolgenden Statusstamm und einen Herausforderungswert bestimmt, der erst bekannt wird, wenn der nachfolgende Statusstamm vollständig bestimmt ist.
2. Wer kann den Knoten betreiben?
Jeder kann Sentinel bedienen, indem er die Software herunterlädt, installiert und ausführt. Um jedoch Token-Belohnungen zu erhalten, muss mindestens ein Sentinel-Lizenzschlüssel erworben werden.
Käufer müssen eine KYC-Prüfung erfolgreich bestehen, um sicherzustellen, dass sie:
nicht in den Vereinigten Staaten
Unterliegt keinen US-amerikanischen OFAC-Sanktionen (OFAC wird in einer US-Sanktionsliste aufgeführt)
Die Sentinel-Knoten, die nicht laufen oder nicht über die entsprechenden Mittel zur Zahlung der Gasgebühren (GAS) verfügen, erhalten keine Belohnungen, auch nicht mit einem Lizenzschlüssel. Daher möchten Betreiber sicherstellen, dass ihre Knoten finanziert, online und betriebsbereit sind.
3. Schiedsrichtervertrag
Referee ist ein intelligenter Vertrag, der die Einhaltung vordefinierter Regeln durchsetzen, die Herkunft von Einsendungen überprüfen und Belohnungen innerhalb des Systems an Gewinner verteilen soll. Der Schiedsrichter-Smart-Vertrag ist eine Schlüsselkomponente im Xai-Ökosystem und für die Verwaltung und Validierung von Ansprüchen der Sentinel-Knoten im Netzwerk verantwortlich. Der Vertrag hat mehrere Schlüsselfunktionen:
3.1 Abgabe der Stellungnahme
Der Schiedsrichtervertrag ermöglicht es Sentinel-Knoten, Ansprüche auf Anfechtungen einzureichen. Diese Funktion kann nur vom Inhaber des Sentinel-Lizenzschlüssels oder seiner in diesem Vertrag genehmigten Adresse aufgerufen werden. Diese Funktion prüft, ob die Challenge noch zur Einreichung offen ist und ob für diese Challenge bereits eine NodeLicense eingereicht wurde.
3.2 Belohnungen erhalten
Der Vertrag enthält eine Funktion, die es Benutzern ermöglicht, Belohnungen für erfolgreiche Ansprüche einzufordern. Diese Funktion prüft, ob die Challenge zur Übermittlung geschlossen wurde und prüft, ob der Besitzer des Knotenschlüssels KYC abgeschlossen hat. Wenn diese Bedingungen erfüllt sind und die Forderung zur Zahlung berechtigt ist, wird die Prämie an den Benutzer gesendet.
3.3 Anspruchs-Hash erstellen und Zahlung prüfen.
Der Vertrag verfügt über eine Funktion, die einen Hash der Sentinel-Berechtigungs-ID, der Challenge-ID, des ChallengerSignedHash in der Challenge und des nachfolgenden Statusstamms erstellt. Anschließend prüft es, ob der Hash unter einem bestimmten Schwellenwert liegt, der auf der Grundlage der Gesamtzahl der geprägten Sentinel-Lizenzen berechnet wird. Liegt der Hash unter dem Schwellenwert, ist der Anspruch zahlungsberechtigt.
Der Schiedsrichtervertrag stellt die Integrität des Xai-Netzwerks sicher, indem er Ansprüche validiert und erfolgreiche belohnt, wodurch Sentinel-Knoten einen Anreiz erhalten, das Netzwerk genau und sorgfältig zu überwachen.
4. Challenger-Komponente
Der Herausforderer ist eine vertrauenswürdige Einheit im Xai-Ökosystem. Es erstellt ein BLS-Schlüsselpaar und registriert den öffentlichen Schlüssel für den Schiedsrichtervertrag. Wenn ein Validator im Xai-Rollup-Protokoll einen Anspruch geltend macht, unterzeichnet der Herausforderer den Anspruch mit seinem privaten Schlüssel und übermittelt die Unterschrift an den Schiedsrichter. Der Schiedsrichter überprüft die Unterschrift und erfasst sie als mit der Aussage verbundene Anfechtung. Dieser Prozess stellt die Integrität der im Xai-Rollup-Protokoll gemachten Ansprüche sicher.
5. Schlüssel (Sentinel-Knotenschlüsselberechtigung, basierend auf NFT)
Der Sentinel-Lizenzschlüssel ist ein einzigartiger, nicht fungibler Token (NFT), der für den Betrieb eines Sentinel-Knotens im Xai-Netzwerk erforderlich ist. Sentinel-Lizenzen dienen als Nachweis der Berechtigung für Knoten, Ansprüche einzureichen und Belohnungen zu erhalten. Die Prägung erfolgt durch Senden der korrekten Menge an ETH, und der Prägepreis wird durch ein System steigender Schwellenwerte bestimmt.
Die Knotenlizenzierung spielt eine Schlüsselrolle im Schiedsrichtervertrag. Wenn ein Knoten einen Anspruch auf eine Herausforderung einreichen möchte, muss er seine Sentinel-Berechtigungs-ID angeben. Der Schiedsrichtervertrag prüft, ob die Sentinel-Lizenz gültig ist und ob der Knoten Eigentümer der Sentinel-Lizenz oder ein zugelassener Betreiber ist (KYC-Abschnitt oben). Wenn diese Bedingungen erfüllt sind, wird der Anspruch des Knotens der Herausforderung vorgelegt.
Sentinel-Berechtigungen spielen auch bei der Inanspruchnahme von Belohnungen für erfolgreiche Ansprüche eine Rolle. Der Schiedsrichtervertrag prüft, ob der Inhaber der Sentinel-Lizenz KYC abgeschlossen hat und ob die Abrechnung zahlungsberechtigt ist. Wenn diese Bedingungen erfüllt sind, wird die Belohnung an den Inhaber der Sentinel-Lizenz gesendet.
Zusammenfassend ist die Sentinel-Berechtigung eine Schlüsselkomponente im Xai-Netzwerk, die den Betrieb von Sentinel-Knoten, die Einreichung von Ansprüchen und die Verteilung von Belohnungen regelt.
6. Knoten herunterladen und ausführen
Um einen Sentinel-Knoten auszuführen, müssen Benutzer lediglich ein bestimmtes Softwarepaket herunterladen. Dieses Paket kann in einer Desktop-Anwendung oder als Befehlszeilentool auf Ihrem Computer verwendet werden. Einfach ausgedrückt handelt es sich bei diesen Apps um Tools, die die Verwendung der Sentinel-Software einfacher machen. Der Zweck dieses Pakets besteht darin, alle für die Ausführung von Sentinel erforderlichen Vorgänge zu automatisieren, sodass es sehr einfach einzurichten und zu verwenden ist, auch wenn Sie technisch nicht versiert sind.
Dieses Paket unterstützt Benutzer bei Aufgaben wie Einrichtung, Verwaltung und Interaktion mit anderen Teilen und verfügt über eine benutzerfreundliche Oberfläche, mit der Benutzer Einstellungen einfach anzeigen und anpassen können. Mit diesem Paket können sich Benutzer stärker darauf konzentrieren, besser zu laufen und mehr Token-Belohnungen zu erhalten. Benutzer können wählen, ob sie dieses Paket mit einer Desktop-Anwendung oder einem Befehlszeilentool ausführen möchten. Beide sind sehr einfach zu verwenden und sorgen für einen reibungslosen Vorgang.
7. Sentinel-Wallet-Funktion
Im Xai-Ökosystem spielt das Sentinel-Wallet eine Schlüsselrolle bei der Interaktion zwischen Sentinel-Knoten und Schiedsrichter-Smart-Contracts. Sentinel Wallet fungiert als Vermittler und ist für die Übermittlung von Erklärungen an den Schiedsrichter im Namen der betreffenden Sentinels verantwortlich. Dies wird durch spezifische Funktionen im Schiedsrichtervertrag erreicht, die nur vom Inhaber des Sentinel-Lizenzschlüssels oder seiner in diesem Vertrag genehmigten Adresse aufgerufen werden können.
Das Sentinel-Wallet kann eine Stellungnahme zur Herausforderung abgeben, indem es die Funktion „submitAssertionToChallenge“ im Schiedsrichtervertrag aufruft. Diese Funktion prüft, ob die Challenge noch zur Einreichung offen ist und ob der Node-Key für diese Challenge bereits übermittelt wurde.
Das Sentry Wallet kann auch Belohnungen für erfolgreiche Ansprüche einfordern, indem es die Funktion „claimReward“ im Schiedsrichtervertrag aufruft. Diese Funktion prüft, ob die Herausforderung zur Einreichung geschlossen wurde und prüft, ob der Inhaber der Sentinel-Lizenz eine „KYC“-Prüfung durchgeführt hat. Wenn diese Bedingungen erfüllt sind und der Anspruch zur Zahlung berechtigt ist, wird die Belohnung an den Eigentümer des Sentinel gesendet.
Zusammenfassend fungiert das Sentinel Wallet als Messenger, der die Interaktion zwischen Knoten und Schiedsrichtern erleichtert und so den reibungslosen Betrieb des Xai-Netzwerks gewährleistet.
8. Lizenz
Die Beziehung zwischen der Anzahl der Lizenzen und den Übermittlungsfähigkeiten des Knotens ist von grundlegender Bedeutung. Obwohl es möglich ist, dass einem Knoten mehrere Lizenzen zugeordnet sind, ist es wichtig zu wissen, dass sich die Anzahl der Lizenzen direkt auf die Commit-Fähigkeit des Knotens auswirkt. Um faire Commit-Kontingente sicherzustellen, wird das Verhältnis von Lizenzen zu Knoteninstanzen im Wesentlichen bei 1:1 gehalten. Durch die Befolgung der oben genannten Grundsätze etabliert das System einen strukturierten Ansatz für die Lizenzierung, die Einreichung von Rechten und den Gesamtbetrieb von Knoten innerhalb des Ökosystems.
9. Software- und Hardwareanforderungen für den Sentry-Knoten
Die Sentinel-Knotensoftware unterstützt Windows-Desktop, Mac und Linux (erfordert 64-Bit). Im Folgenden sind die aktuellen Ressourcen aufgeführt, die zum Ausführen der Sentinel-Knotensoftware für bis zu 100 Lizenzschlüssel erforderlich sind:
4 GB RAM
2 CPU-Kerne
60 GB Speicherplatz
x86/X64-Prozessor (unterstützt ARM-Prozessor, z. B. Apple M1/M2-Chip)
Stabile Internetverbindung
Beim Hinzufügen zusätzlicher Schlüssel zu einem Knoten sollten sich idealerweise die Hardwarefunktionen entsprechend erhöhen. Es ist jedoch nicht zwingend erforderlich, jedem Schlüssel eine eigene Maschine zuzuordnen. Es wird erwartet, dass das System skalierbar ist, um Dutzende von Schlüsseln auf einem einzigen Computer unterzubringen, und möglicherweise noch mehr.
Hinweis: Diese Hardwareanforderungen können sich ändern.
10. Geschätzte Belohnungen für das Sentry-Knotennetzwerk
Weitere Informationen zum XAI-Token-Wirtschaftsmodell finden Sie unter: Interpretation der „Token-Ökonomie“ des XAI-Projekts
Hier sind drei Szenarien zur Schätzung der Xai-Belohnungen, die Sie durch den Betrieb eines Sentry-Knotens verdienen könnten. Diese drei Szenarien basieren auf den folgenden Annahmen:
Die Summe aus XAI und esXAI wird niemals 2.500.000.000 überschreiten. Da das Xai-Ökosystem dynamisch ist, ist es unmöglich, die monatlichen Token-Belohnungen für jeden Sentry-Schlüssel genau vorherzusagen.
100 % des GAS werden verbrannt, daher gibt es keine Garantie dafür, dass die Versorgung immer inflationär sein wird, es kann sogar deflationär sein.
Die Xai Foundation wird nicht mehr als 50.000 Sentry-Schlüssel verkaufen (ein Knoten kann mehrere Schlüssel laden). Dies wird voraussichtlich 2-3 Jahre dauern. Sentry-Schlüssel werden mit der Zeit teurer.
Der monatliche esXAI-Betrag pro Sentry-Schlüssel kann auch je nach Anzahl der Stake-Teilnehmer im Ökosystem schwanken.
Die Bedeutung der folgenden drei Tabellen besteht darin, dass unter der unterschiedlichen Zirkulation von XAI- und esXAI-Token die Anzahl der im Netzwerk aktivierten Knotenschlüssel und die entsprechenden erwarteten monatlichen Token-Belohnungen pro Schlüssel:
Szenario A-Schätzung: Wenn insgesamt 750.000 XAI- und esXAI-Token im Umlauf sind, erhält jeder Sentry-Schlüssel esXAI-Belohnungen gemäß der folgenden Tabelle:
Szenario B-Schätzung: Wenn insgesamt 1.250.000.000 XAI- und esXAI-Token im Umlauf sind, erhält jeder Sentry-Schlüssel esXAI-Belohnungen gemäß der folgenden Tabelle:
Szenario C-Schätzung: Wenn insgesamt 2.187.500.000 XAI- und esXAI-Token im Umlauf sind, erhält jeder Sentry-Schlüssel esXAI-Belohnungen gemäß der folgenden Tabelle:
Teil 2: XAI wird von Arbitrum (ARB) entwickelt und gepflegt, daher müssen wir etwas Licht auf die Architektur von Arbitrum werfen:
1.Nitro-Entscheidung
Alle Arbitrum-Ketten basieren auf Arbitrum Nitro, der zugrunde liegenden Technologie für alle Ketten im Ökosystem. Nitro führt eine abgespaltene Version von Geth aus und verwendet WebAssembly als betrugssichere zugrunde liegende virtuelle Maschine.
2.Anytrust-Entscheidung
Anytrust ist ein Arbitrum-Protokoll, das die Datenverfügbarkeit durch eine Sammlung von Lizenzgebern namens Data Availability Committee (DAC) verwaltet. Dieses Protokoll reduziert die Transaktionsgebühren, indem es eine zusätzliche Vertrauensannahme hinsichtlich der Datenverfügbarkeit einführt, anstatt den vertrauenswürdigen Datenverfügbarkeitsmechanismus von Ethereum zu verwenden.
3. Einführung in Arbitrum 2 Ebenen, die Sie vielleicht kennen
Arbitrum Nova ist ein Beispiel für eine AnyTrust-Kette; Arbitrum One ist eine weitere alternative Kette, die das rein vertrauenswürdige (und L1-Gas-intensivere) Arbitrum Rollup-Protokoll implementiert. Beide Ketten basieren auf Nitro.
4.Orbit-Kette
Mit Arbitrum Orbit können Dritte ihre eigenen, selbstverwalteten Arbitrum Rollup- und AnyTrust-Ketten erstellen. Arbitrum bietet Rollup- und AnyTrust-Technologien für maximale Flexibilität beim Aufbau von Orbit-Ketten. Wie alle Ketten im Arbitrum-Ökosystem basieren sowohl Arbitrum Rollups als auch die Arbitrum Anytrust Orbit-Kette auf Nitro als zugrunde liegender Technologie.
5. Verstehen Sie die Grundsituation von Xai
Lassen Sie uns Xai im obigen Kontext verstehen. Xai fungiert als Arbitrum Orbit-Kette und nutzt die Anytrust-Technologie für maximale Geschwindigkeit und minimale Kosten. Im Gegensatz zu den meisten „selbstverwalteten“ Orbit-Ketten profitiert Xai vom direkten technischen Support von Offchain Labs. Diese Art der Unterstützung ist für andere Orbit-Ketten undenkbar! und ist eine Schlüsselkomponente von Xais strategischem Spielplan innerhalb des Arbitrum-Ökosystems.
Teil 3: Nachdem Sie die oben genannten Konzepte verstanden haben, wollen wir die Architektur genauer verstehen:
1.AnyTrust: Revolutionäre Blockchain-Infrastruktur
Im Rahmen des AnyTrust-Frameworks und als hochmoderne Variante der Arbitrum Nitro-Technologie nutzt Offchain Labs Innovationen, um einige der dringendsten Herausforderungen im Blockchain-Bereich zu lösen. AnyTrust eröffnet uns eine neue Perspektive, indem es leichte Vertrauensannahmen einbezieht, die Kosten erheblich senkt und gleichzeitig eine starke Datenverfügbarkeit und -sicherheit gewährleistet.
2. Reduzieren Sie die Kosten durch Vertrauensannahmen
Im Kern des Arbitrum-Protokolls müssen alle Arbitrum-Knoten (einschließlich Validatoren, die die Korrektheit der Kette überprüfen und die genauen Ergebnisse abstecken) auf die Daten jeder Transaktion der zweiten Schicht (L2) im Posteingang der Arbitrum-Kette zugreifen. Traditionell gewährleistet das Arbitrum-Rollup den Datenzugriff durch die Veröffentlichung von Daten als Anrufdaten auf Layer 1 (L1) Ethereum, ein Prozess, der erhebliche Ethereum-Gasgebühren generiert, die einen wesentlichen Kostenfaktor in Arbitrum darstellen.
3.Ketsets Flexibilität
Ketsets spielen eine Schlüsselrolle in der Architektur von AnyTrust. Sie geben die öffentlichen Schlüssel der Ausschussmitglieder und die Anzahl der erforderlichen Signaturen zur Überprüfung des Data Availability Certificate (DACert) an. Ketsets bieten Flexibilität für wechselnde Ausschussmitglieder und ermöglichen es Ausschussmitgliedern, ihre Schlüssel nach Bedarf zu aktualisieren.
4. Datenverfügbarkeitszertifikate (DACerts)
Ein Grundkonzept in AnyTrust ist das Datenverfügbarkeitszertifikat (DACert). Ein DACert besteht aus dem Hash des Datenblocks, einer Ablaufzeit und dem Nachweis, dass N-1-Komiteemitglieder das Paar (Hash, Ablaufzeit) signiert haben. Dieser Beweis umfasst einen Hash des für die Signatur verwendeten Schlüsselsatzes, eine Bitmap, die angibt, welche Ausschussmitglieder unterzeichnet haben, und eine BLS-Gesamtsignatur auf der BLS12-381-Kurve, die den Unterzeichner nachweist.
Aufgrund der 2-von-N-Vertrauensannahme dient DACert als Beweis dafür, dass die Daten eines Blocks bis zu einer bestimmten Ablaufzeit für mindestens ein ehrliches Ausschussmitglied verfügbar sind. Diese Vertrauensannahme ist die Grundlage für die Zuverlässigkeit und Sicherheit der Datenverfügbarkeit innerhalb des AnyTrust-Frameworks.
5. Dualer Datenfreigabemechanismus
AnyTrust führt eine duale Methode zum Veröffentlichen von Datenblöcken auf L1 ein. Zusätzlich zur traditionellen Methode der Veröffentlichung vollständiger Datenblöcke ermöglicht es auch die Ausstellung von DACerts, also Zertifikaten, die die Verfügbarkeit von Daten belegen. Der L1-Posteingangsvertrag überprüft die Gültigkeit von DACerts, einschließlich der Bezugnahme auf gültige Kesets, die im DACert angegeben sind.
Der L2-Code, der für das Lesen der Daten aus dem Posteingang verantwortlich ist, ist für die nahtlose Verarbeitung beider Datenformate ausgelegt. Wenn ein DACert gefunden wird, führt es Gültigkeitsprüfungen durch, einschließlich der Sicherstellung, dass die Anzahl der Unterzeichner den Ketsets-Anforderungen entspricht, der Validierung aggregierter Signaturen und der Bestätigung des Ablaufs nach dem aktuellen L2-Zeitstempel. Gültige DACerts stellen sicher, dass der Datenblock zugänglich ist und von L2-Code ausgenutzt werden kann.
6. Datenverfügbarkeitsserver (DAS)
Ausschussmitglieder betreiben den Data Availability Server (DAS), der zwei wichtige APIs bereitstellt:
(1) Sortierer-API: Diese JSON-RPC-Schnittstelle wurde für die Verwendung durch den Sortierer der Arbitrum-Kette entwickelt und ermöglicht es dem Sortierer, Datenblöcke zur Speicherung an DAS zu übermitteln.
(2) REST-API: Das RESTful HTTP(S)-basierte Protokoll wurde für eine breitere Zugänglichkeit entwickelt und ermöglicht den Abruf von Datenblöcken über Hash. Es ist vollständig zwischenspeicherbar und kann in Verbindung mit Caching-Proxys oder CDNs eingesetzt werden, um die Skalierbarkeit zu verbessern und vor potenziellen DoS-Angriffen zu schützen.
7. Interaktion zwischen Sortierer und Ausschuss
Wenn der Arbitrum-Sortierer beabsichtigt, einen Datenstapel über das Komitee zu veröffentlichen, sendet er die Daten und eine Ablaufzeit parallel über RPC an alle Komiteemitglieder. Jedes Ausschussmitglied speichert die Daten, signiert das Paar (Hash, Ablaufzeit) mit seinem BLS-Schlüssel und sendet die Signatur und den Erfolgsindikator an den Sequenzer zurück. Sobald genügend Signaturen gesammelt wurden, aggregiert der Sequenzer sie, um ein gültiges DACert für (Hash, Ablaufzeit)-Paare zu erstellen. Dieses DACert wird dann im L1-Posteingangsvertrag veröffentlicht und macht es für die AnyTrust-Kettensoftware von L2 zugänglich. Für den Fall, dass der Sequenzer innerhalb des angegebenen Zeitrahmens nicht genügend Signaturen sammeln kann, wendet er eine „Fallback-to-Rollup“-Strategie an und veröffentlicht die vollständigen Daten direkt in der L1-Kette. L2-Software zeichnet sich dadurch aus, dass sie beide Datenveröffentlichungsformate (über DACert oder vollständige Daten) versteht und jedes Format angemessen handhabt. Zusammenfassend stellt AnyTrust als bahnbrechende Innovation innerhalb des Offchain Labs-Ökosystems einen entscheidenden Fortschritt im Hinblick auf Datenverfügbarkeit, Sicherheit und Kosteneffizienz der Blockchain-Infrastruktur dar. Mit einer vernünftigen Vertrauensannahme und einem neuartigen Ansatz zur Datenveröffentlichung ebnet AnyTrust den Weg für skalierbarere, zugänglichere und sicherere Blockchain-Lösungen.
Teil 4: Unter Berücksichtigung der oben genannten Konzepte erklären wir nun, warum Sentinel-Knoten wichtig sind: das Cheater-Checking-Problem, warum das Validator-Dilemma schwieriger ist, als Sie denken, und die Lösung!
Der Autor ist Ed Felten, Chefwissenschaftler bei Arbitrum
In Blockchain-Systemen besteht ein gängiges Entwurfsmuster darin, dass eine Partei einige Arbeiten erledigt und für korrektes Verhalten eine Kaution hinterlegt und dann andere auffordert, die Arbeit zu überprüfen und diese Kaution einzuziehen, wenn sie den Arbeiter beim Betrügen erwischt. Man könnte es das Designmuster „Assert-Challenge“ nennen. Wir tun dies in Arbitrum und haben kürzlich auch Vorschläge wie Optimistic Rollup in den Nachrichten gesehen.
Diese Systeme können vom Validator-Dilemma betroffen sein, das im Grunde darin besteht, dass es keinen Sinn macht, die Arbeit einer Person zu überprüfen, wenn man weiß, dass sie nicht betrügt. Wenn Sie ein Designer sind, möchten Sie nachweisen, dass Ihr System anreizkompatibel ist. Das bedeutet, dass es zu keinem Betrug kommt, wenn sich alle konsequent an ihre Anreize halten. Dies ist ein Bereich, in dem die Intuition Sie in die Irre führen kann. Dieses Problem ist viel schwieriger, als es scheint, wie wir sehen werden, wenn wir unten die Anreize der Parteien darlegen.
Ein super einfaches Modell
Wir beginnen damit, das einfachste Modell zu erstellen, das wir können. Angenommen, es gibt zwei Spieler. Der Behaupter macht eine Aussage, die wahr oder falsch sein kann. Der Prüfer kann die Behauptung des Behauptungsstellers überprüfen oder sich dafür entscheiden, nichts zu unternehmen, vermutlich unter der Annahme, dass der Behauptungssteller wahrscheinlich die Wahrheit sagt. Wir gehen davon aus, dass die Prüfkosten des Prüfers C betragen. Wenn der Prüfer prüft und feststellt, dass der Prüfer betrogen hat, erhält der Prüfer eine Belohnung von R. (R umfasst alle Vorteile, die dem Prüfer durch das Erkennen von Betrug entstehen. Dazu gehören Vorteile, die „außerhalb des Systems“ erzielt werden, sowie alle Vorteile, die durch ein erhöhtes Vertrauen in das System erzielt werden.) Wenn der Prüfer nicht erwischt wird, gilt „Unter Betrug“. , verliert der Prüfer L, zum Beispiel weil der Betrüger dem Prüfer auf betrügerische Weise wertvolle Gegenstände wegnehmen kann.
Jetzt müssen wir uns um zwei Bedrohungen Sorgen machen: Bestechung und Faulheit. Unter Bestechung versteht man die Möglichkeit, dass der Asserter den Prüfer besticht, damit dieser nicht prüft, wodurch der Asserter unbemerkt betrügen kann. Wir können dies verhindern, indem wir sicherstellen, dass der Asserter eine sehr große Anzahlung treuhänderisch hinterlegt, die größer ist als der Gesamtwert im System, und den Prüfer bezahlt, wenn ein Betrug festgestellt wird, so dass der Asserter nicht bereit ist, mehr als die Belohnungs-Rs des Prüfers zu zahlen bestechen. Dadurch wird Bestechung verhindert, allerdings muss das System vollständig besichert sein, was sehr teuer sein kann.
Eine weitere Bedrohung ist Faulheit, das Risiko, dass der Prüfer beschließt, die Arbeit des Behaupters nicht zu prüfen. (Denken Sie daran, dass Dame möglicherweise sagen, dass sie checken, dies aber nicht tatsächlich tun.) Schauen wir uns die Anreize für Checker an, um herauszufinden, ob dies eine vernünftige Strategie ist.
Angenommen, der Asserter betrügt mit der Wahrscheinlichkeit X. Der Dienstprogramm des Inspektors ist nun wie folgt:
Wenn der Rezensent prüft: RX-C
Wenn der Prüfer nicht prüft: -XL
Eine Prüfung lohnt sich nur dann, wenn der Nutzen der Prüfung größer ist als der Nutzen der Nichtprüfung, also wenn X > C/(R+L). Hier ist die schlechte Nachricht: Der Asserter kann zufällig betrügen, mit einer Wahrscheinlichkeit kleiner als C/(R+L). Ein rationaler Prüfer wird dies nie überprüfen, sodass der Asserter niemals beim Betrügen erwischt wird.
Geben wir ein paar Zahlen ein. Wenn die Kosten für die Überprüfung jeder Transaktion 0,10 US-Dollar betragen und der Prüfer ein Kopfgeld von 75 US-Dollar erhält, wenn er einen Betrug erkennt, aber 25 US-Dollar verliert, wenn er keinen Betrug erkennt, kann der Prüfer tausendmal ungestraft betrügen. Wenn wir wollen, dass dieses System Tausende von Transaktionen durchführt, dann haben wir ein großes Problem. Offensichtlich können wir in diesem Modell nichts tun, um die Betrugswahrscheinlichkeit auf Null zu reduzieren. Wir können nur auf ein überbesichertes System hoffen, sodass der Nenner von C/(R+L) größer wird.
Das ist ein überraschend robustes Ergebnis – im schlechten Sinne. Es kommt überhaupt nicht auf die Anreize des Anspruchsstellers an. Solange der Asserter durch erfolgreiches Betrügen einen Vorteil ungleich Null erhält, kann er dies mit einiger Wahrscheinlichkeit tun, wohlwissend, dass es sich für den Prüfer nicht lohnt, dies zu überprüfen. Dieses Ergebnis hängt auch nicht davon ab, wie viel Zeit wir dem Inspektor für die Erledigung des Auftrags geben oder ob wir den (vermeintlichen) Inspektor bezahlen. Vielleicht denken Sie jetzt, das Problem sei, dass es nur einen Inspektor gibt. Würde das Hinzufügen weiterer Steine die Wahrscheinlichkeit eines Betrugs verringern? Überraschenderweise ist das nicht der Fall.
Das Hinzufügen von Zensoren trägt nicht dazu bei, Betrug zu verhindern
Lassen Sie uns noch einmal ein einfachstes Modell formulieren. Mittlerweile sind es zwei Inspektoren, die unabhängig voneinander agieren. Jeder Prüfer zahlt C, wenn er prüft, und wenn jemand prüft und dabei erwischt, wie der Prüfer betrügt, erhält der erfolgreiche Prüfer eine Belohnung von R, oder wenn beide geprüft haben, wird die Belohnung zu gleichen Teilen zwischen beiden aufgeteilt. (Wenn Sie möchten, können Sie einem von ihnen eine zufällige volle Belohnung von R geben, falls alle checken. Dies hat keinen Einfluss auf die Strategie oder die Ergebnisse von irgendjemandem.) Wie zuvor verliert jeder Checker L, wenn der Asserter betrügt, ohne zu bekommen erwischt.
Es gilt weiterhin: Wenn der Asserter weniger als C/(R+L) der Zeit betrügt, lohnt es sich für den Prüfer nicht, zu prüfen, da der Nutzen der Prüfung geringer ist als der Nutzen der Nichtprüfung. Tatsächlich ist das Anreizproblem schlimmer als zuvor, da die Prüfkosten pro Prüfer immer noch C betragen, aber die erwartete Belohnung für einen erfolgreichen Prüfer, der das Betrügen erwischt, weniger als R beträgt, da die Belohnung manchmal aufgeteilt werden muss – die erwartete Belohnung wird es tun in R/2 und R sein. Wenn die erwartete Belohnung bR ist, wobei b zwischen 0,5 und 1 liegt, kann der Asserter bis zu C/(bR+L) Zeit betrügen – das ist mehr unentdeckter Betrug, als wenn es nur einen Prüfer gäbe! (Die Mathematik wird etwas komplizierter, da der Wert von b von der Strategie des Prüfers abhängt und seine Strategie von b abhängt, aber es sollte klar sein, dass er manchmal die Belohnung aufteilen muss. Außerdem wird auch der effektive Wert von L reduziert , da man dies nicht tut. Die Checker dürfen ihr L nicht verlieren, weil sie von anderen Checkern überprüft werden.
Ein Bereich, in dem die Einführung von Zensoren wirklich hilfreich wäre, ist die Verhinderung von Bestechung. Bei zwei Kontrolleuren muss der Ansprecher jedem Ansprecher ein Bestechungsgeld von mehr als R zahlen, was das Bestechungsgeld doppelt so teuer macht und einen Einsatz von 50 % anstelle des vollen Einsatzes ermöglicht. Der Nachteil besteht jedoch darin, dass das Ausmaß des Betrugs zunimmt.
Ich werde hier nicht auf die ganze Mathematik eingehen, aber unter vernünftigen Annahmen könnte die Erhöhung von einem Stein auf zwei zu einem Anstieg des unentdeckten Betrugs um 50 % führen.
Das Hinzufügen von Zensoren macht die Sache noch schlimmer!
Sie können weitere Steine hinzufügen und die Sache wird noch schlimmer. Wenn die Anzahl der Prüfer zunimmt, muss sich der Prüfer mehr darum kümmern, dass die Belohnung auf mehrere Arten aufgeteilt wird, sodass die erwartete Belohnung für jeden erfolgreichen Prüfer allmählich abnimmt, was dazu führt, dass die Wahrscheinlichkeit, dass der Prüfer sicher schummelt, allmählich zunimmt. Aus dieser Perspektive ist das Worst-Case-Szenario, dass jeder auf der Welt zum Zensor werden könnte. Das ist zwar nicht unbedingt schlimm, da die Lage mit zunehmender Zensierung noch schlimmer wird, aber es wird sicherlich nicht dazu beitragen, Betrug zu verhindern, selbst wenn es das Bestechungsrisiko effektiv ausschließt.
Sind Sie sicher, dass Ihr System mit Anreizen kompatibel ist?
Wenn Sie über ein System verfügen, das zu dieser Art von Modell passt, und Sie glauben, dass es anreizkompatibel ist, müssen Sie sorgfältig darüber nachdenken, warum. Insbesondere müssen Sie erklären, warum der Prüfer die Prüfung durchführen würde, auch wenn er davon ausgeht, dass der Asserter wahrscheinlich nicht betrügen wird. Es reicht nicht aus, nur eine hohe Betrugsstrafe zu verhängen. Eine bloße Belohnung für die Ergreifung von Betrügern reicht nicht aus. Es reicht nicht aus, nur viele Steine zu haben – es kann sogar die Situation verschlimmern. Warum ist Ihr System immun?
Diese Herausforderung gilt für Systeme wie Optimistic Rollup. Wenn wir über Arbitrum sprechen, gilt das auch für uns.
Unter Berücksichtigung des oben Gesagten erzielen herkömmliche Methoden zur Anreizprüfung nicht die gewünschten Ergebnisse – es gibt eine grundlegende Betrugsrate, unterhalb derer die Prüfer die Prüfung als nicht lohnenswert erachten. Abschließend:
Es gibt zwei Akteure: einen Behauptungssteller, der eine Behauptung aufstellt, ob sie wahr oder falsch ist, und einen Prüfer, der die Behauptung mit einem gewissen Rechenaufwand überprüfen kann. Wenn der Prüfer prüft, ist sein Nutzen RX-C, wenn er nicht prüft, ist sein Nutzen -XL, wobei R die Belohnung für das Erkennen eines Betrugs ist, C die Kosten für das Prüfen und L der Verlust des Prüfers, weil er einen Betrug nicht entdeckt hat , X ist die Wahrscheinlichkeit, dass der Asserter betrügt (vom Asserter gewählt). Einige Algebra zeigt, dass if
Um dieses Problem zu lösen und eine Situation zu schaffen, in der ein anreizorientierter Prüfer immer prüft, müssen wir die Anreize des Prüfers ändern. Das Grundproblem besteht darin, dass im ursprünglichen Modell die positiven Anreize für Prüfer zum Prüfen alle proportional sind Wenn wir einen Prüfanreiz wollen, der unabhängig davon funktioniert, müssen wir einen Prüfanreiz oder einen Abschreckungsanreiz für die Nichtprüfung schaffen, der unabhängig von den Aktionen des Bestätigers ist.
TrueBit versucht dies zu erreichen, indem es der Menge der Behauptungen absichtlich falsche Behauptungen hinzufügt und im Wesentlichen X durch X plus eine Konstante ersetzt. Bei diesem Ansatz gibt es einige Probleme. (Das Originalpapier von Arbitrum enthält einen Abschnitt zu den Motivationsproblemen von TrueBit.)
Konzentrieren Sie sich auf Herausforderungen
Wir verwenden einen anderen Ansatz, den wir Konzentration auf die Herausforderung nennen. Die Idee ist, dass der Asserter, wenn er einen Wert f(x) berechnet, zunächst x und eine kryptografische Herausforderung ausgibt. Um auf die Herausforderung richtig reagieren zu können, muss der Prüfer f(x) kennen. Erst nachdem die Herausforderung aufgetreten ist, veröffentlicht der Asserter f(x) – zu diesem Zeitpunkt hat der Prüfer bereits die harte Arbeit der Berechnung von f(x) erledigt, sodass er keinen Anreiz hat, faul zu sein. (Weitere Details zur Vereinbarung folgen.)
Um die Anzahl der hierfür erforderlichen On-Chain-Transaktionen zu reduzieren, werden wir die Dinge so arrangieren, dass die richtige Antwort auf eine Herausforderung durch einen Prüfer normalerweise Schweigen ist. In seltenen Fällen muss der Prüfer jedoch eine sehr kleine Transaktion in der Kette veröffentlichen. Wenn der Prüfer die falsche Antwort gibt – Stille, wenn er freigegeben werden soll, oder Stille, wenn er freigegeben werden soll – verliert er eine kleine Anzahlung.
Lassen Sie uns das ursprüngliche Anreizmodell anpassen, um Aufmerksamkeitsherausforderungen einzubeziehen. Wir benötigen zwei neue Parameter (die wir beide auswählen können): P, der Prozentsatz der Zeit, in der die richtige Antwort des Prüfers gepostet wird, und A, die Strafe, wenn der Prüfer eine falsche Antwort gibt. Der Nutzen des Inspektors ist nun:
Wenn aktiviert: RX-C
Wenn nicht, überprüfen Sie: -LX-PA
Die wichtigste Beobachtung ist, dass das Überprüfen die optimale Strategie ist, solange PA > C ist, unabhängig davon, wie hoch X (die Wahrscheinlichkeit des Betrugs) ist.
Sehr niedrige Kosten
Um die Kosten abzuschätzen, schauen wir uns ein konkretes Beispiel an. Nehmen wir an, dass alle fünf Minuten eine Behauptung vorliegt und die Kosten für die Überprüfung 0,001 $ betragen. Wenn wir die Wahrscheinlichkeit P auf 0,3 % setzen, muss der Prüfer eine Anzahlung von 3 $ leisten. Nun betragen die Kosten des Prüfers pro Behauptung 0,0003 US-Dollar an Gasgebühren (die 0,10 US-Dollar Gasgebühr für die Veröffentlichung seiner nicht stillen Antwort, multipliziert mit der Wahrscheinlichkeit von 0,3 %, die er posten muss), plus etwa 0,0003 US-Dollar, um seinen Einsatz von 3 US-Dollar für fünf Minuten zu sperren. Die Gesamtsumme Die Zinskosten betragen 0,0006 $ pro Geltendmachung.
Erweiterung für mehrere Prüfer
Die Fokusherausforderung lässt sich gut mit mehreren Prüfern skalieren. Das Protokoll gibt eine Herausforderung aus, die sich auf jeden Prüfer unterschiedlich auswirkt und jeden Prüfer dazu zwingt, f(x) selbst zu berechnen. Für jeden Prüfer fallen die gleichen Kosten an (in unserem Fall 0,0006 $ pro Behauptung).
In einem offenen System ist jeder berechtigt, die Berechnungen zu überprüfen, und Sie können jedem erlauben, sich als Prüfer zu registrieren und die erforderliche kleine Einzahlung zu tätigen. Dadurch haben sie Anspruch auf Aufmerksamkeitsherausforderungen und erhalten möglicherweise eine Vergütung von Dapp-Entwicklern. Jeder kann die falschen Behauptungen eines Anspruchsstellers anfechten, aber nur registrierte Prüfer müssen mit Aufmerksamkeitsprüfungen rechnen.
Technische Einzelheiten der Vereinbarung
Nachdem wir nun verstanden haben, was die Fokussierung auf Herausforderungen für uns bewirken kann, wollen wir uns mit den technischen Details ihrer Funktionsweise befassen.
Jeder Prüfer verfügt über einen privaten Schlüssel k und einen entsprechenden öffentlichen Schlüssel gᵏ, die in einer geeigneten Gruppe definiert sind. Der öffentliche Schlüssel jedes Prüfers ist jedem bekannt. Wir werden uns auch auf eine geeignete Hash-Funktion H verlassen.
Um eine Herausforderung für die Berechnung von f(x) zu stellen, bei der die Funktion f im Voraus bekannt ist, generiert der Asserter einen Zufallswert r und gibt dann (x, gʳ) als Herausforderung aus.
Ein Prüfer, der den privaten Schlüssel k besitzt, sollte auf die Herausforderung nur dann mit der Veröffentlichung einer kleinen Transaktion reagieren, wenn H(gʳᵏ, f(x)) < T, wobei T ein geeignet gewählter Schwellenwert ist. Beachten Sie, dass nur der Asserter (der r kennt) und dieser bestimmte Prüfer (der seinen privaten Schlüssel k kennt) den Hash berechnen können, da sie die einzigen sind, die gʳᵏ berechnen können. Beachten Sie außerdem, dass die Berechnung des Hash die Kenntnis von f(x) erfordert.
Nachdem die Prüfer etwas Zeit hatten, ihre Antworten auf die Herausforderung zu posten, kann der Asserter sein f(x) posten und wenn ein Prüfer damit nicht einverstanden ist, wird es wie üblich angefochten. An dieser Stelle kann der Behaupter jedem Prüfer falsche Antworten vorwerfen; der Behaupter muss r ausgeben, um seine Anschuldigung zu untermauern. Der Bergmann oder der Vertrag kann prüfen, ob die Anschuldigung richtig ist, und den Verletzer bestrafen. Wenn die Behauptung des Klägers zu f(x) jedoch letztendlich nicht als richtig akzeptiert wird, wird die Anschuldigung ignoriert. Wenn gegen einen Prüfer eine Geldstrafe verhängt wird, erhält der Antragsteller die Hälfte des verfallenen Geldes und die andere Hälfte wird vernichtet.
Dieser Ansatz gibt dem Prüfer die richtigen Anreize. Um zu wissen, wie ein Prüfer auf eine Herausforderung reagieren soll, müssen der private Schlüssel und f(x) des Prüfers bekannt sein, sodass jeder Prüfer f(x) berechnen möchte. Sofern der Prüfer f(x) nicht selbst berechnet, kann er das Protokoll nicht sicher durchsetzen. Die Antworten anderer Prüfer sind für die Bestimmung von f(x) nicht hilfreich, da sie auf den privaten Schlüsseln dieser Prüfer basieren. Wenn sich ein Prüfer darauf verlässt, dass jemand anderes ihm f(x) mitteilt, hat er keine Möglichkeit, den beanspruchten Wert zu überprüfen (außer, f(x) selbst zu berechnen), und der Prüfer riskiert eine Strafe, wenn er falsch ist. Es besteht sogar ein Anreiz für eine Partei, zu versuchen, den Prüfer über f(x) in die Irre zu führen – das ist der Behauptungssteller, der vom Fehler des Prüfers profitiert und diese Gewinne möglicherweise dazu nutzt, die „Freunde“ des Prüfers zu bestechen, damit sie dem Prüfer falsche Informationen liefern .
Optimierung und Fazit
Es gibt mehrere Tricks, um dieses Protokoll effektiver zu machen. Beispielsweise könnten wir eine Assertion mit der nächsten Challenge in einer On-Chain-Transaktion bündeln, sodass die Challenge die Anzahl der Transaktionen nicht erhöht. Wenn P klein ist (z. B. 0,3 % in unserem Beispiel) und die Anzahl der Prüfer nicht sehr groß ist, müssen Prüfer selten Transaktionen in die Kette schreiben, sodass sich die Gesamtauswirkungen des Protokolls auf die Anzahl der Transaktionen in der Kette ändern werden der Kleinste sein.
Bei geschickter Implementierung sollten die Kosten dieses Protokolls im Vergleich zu den Vorabkosten für die Ausgabe von Behauptungen in der Kette sehr niedrig sein. In unserem Fall erhöht das Hinzufügen von Aufmerksamkeitsherausforderungen zum bestehenden Assertion-Challenge-Protokoll die Gesamtkosten um weniger als 1 %.
Und die Vorteile sind beträchtlich – wir erhalten ein anreizkompatibles Prüfprotokoll, das gegen das Dilemma des Prüfers immun ist. Solange mindestens ein Prüfer rational ist, werden die Ansprüche des Behauptungsstellers immer überprüft.
Weitere Informationen zum Projekt finden Sie unter: Öffentliche Spielkette Xai: Binance Square-Datenbank