Nutzung gemeinsamer Sicherheit für sichere kettenübergreifende Interoperabilität

Angesichts der Tatsache, dass Angriffe auf Blockchain-Brücken zu Milliardenverlusten führen, ist es nicht verwunderlich, dass Diskussionen über Cross-Chain-Sicherheit oft heftige Debatten auslösen. Wir glauben jedoch an einen pragmatischeren Ansatz, bei dem das Problem der sicheren Interoperabilität von Grund auf analysiert und Mechanismen entwickelt werden, um die Sicherheitsgarantien für Cross-Chain-Anwendungen und ihre Benutzer zu erhöhen. In diesem Artikel untersuchen wir das Konzept der und erklären, wie gemeinsame Sicherheitsdesigns (wie Lagrange State Committees) die Kosten für das Bootstrapping sinnvoller Sicherheitseigenschaften für Interoperabilitätsprotokolle senken können. Während wir uns auf die gemeinsame Sicherheit für kettenübergreifende Kommunikationsprotokolle konzentrieren, kann jede dezentrale Anwendung – unabhängig vom Anwendungsfall – diese aufkommende Technologie nutzen, um eine ausreichende Dezentralisierung und Vertrauensminimierung zu erreichen, ohne übermäßigen Betriebsaufwand zu verursachen. gemeinsamen Sicherheit Eine informelle Einführung in die gemeinsame Sicherheit „Geteilte Sicherheit“ bezieht sich auf Sicherheit, die ein Protokoll von einer externen Quelle ableitet. In einem geteilten Sicherheitsschema werden von Teilnehmern eines Protokolls gebündelte Ressourcen (z. B. Kapital oder Rechenleistung) verwendet, um wirtschaftliche Sicherheit für ein anderes Protokoll zu schaffen. Geteilte Sicherheit unterscheidet sich vom Standardmodell, bei dem jedes Netzwerk für seine Sicherheit verantwortlich ist. Öffentliche Blockchains wie Bitcoin und Ethereum kombinieren beispielsweise Konsensalgorithmen mit Sybil-Resistenzmechanismen – wie Proof of Work oder Proof of Stake – um Lebendigkeit zu garantieren und gleichzeitig die Kosten feindlicher Angriffe (z. B. , , , und ) zu erhöhen. Sybil-Angriffe Langstreckenangriffe Eclipse-Angriffe Time-Bandit-Angriffe Bestechungsangriffe Obwohl gemeinsame Sicherheitssysteme unterschiedlich funktionieren, drehen sich die Ziele im Allgemeinen um zwei Dinge: Steigerung der Kapitaleffizienz in Blockchain-Netzwerken ohne Schaffung zusätzlicher Risiken (Risikostapelung) oder Einführung zusätzlicher Sicherheitsannahmen. Verbesserung der Kapazität von Blockchain-Netzwerken (insbesondere neuer Protokolle) zum Schutz vor ungültigen Zustandsübergängen, Reorganisationen, Zensurresistenz und anderen Angriffen auf die Aktivität und Sicherheit eines Protokolls. Gemeinsame Sicherheit ist nicht gerade ein neues Konzept. wurde beispielsweise 2011 eingeführt und ermöglichte es Minern, mit demselben kryptografischen Proof-of-Work (PoW) Blöcke auf zwei (oder mehr) verschiedenen PoW-Ketten zu erstellen, die implementierten. Dies ermöglichte neueren PoW-basierten Protokollen (wie Namecoin und Rootstock), deren native Token nicht genug Wert erlangt hatten, um das Interesse von Minern zu wecken, die Sicherheit zu teilen, indem Rechenressourcen, die für die Sicherung des Bitcoin-Netzwerks vorgesehen waren, wiederverwendet wurden, um die Schwierigkeit der Blöcke auf dem neuen Protokoll zu erhöhen. Merge-Mining den Nakamoto-Konsens Allerdings gilt Merge Mining aufgrund seiner fehlenden nachvollziehbaren Sicherheit als schwache Form der wirtschaftlichen Sicherheit für dezentrale Netzwerke. In der wissenschaftlichen Literatur spiegelt nachvollziehbare Sicherheit die Fähigkeit eines Protokolls wider, Knoten zu erkennen, die (nachweislich) gegen Protokollregeln verstoßen, und böswilliges Verhalten zu bestrafen. Beispielsweise erfordern Proof of Stake-basierte Protokolle, dass Knoten Sicherheiten sperren (indem sie den nativen Token des Protokolls einsetzen), bevor sie am Konsens teilnehmen, und können diese Sicherheiten zerstören/einfrieren („slashen“), wenn Beweise für das Fehlverhalten eines Validierers auftauchen. Beim Merge Mining können Knoten, die absichtlich ungültige Blöcke in der Merge-Mining-Kette akzeptieren, nicht zuverlässig erkannt werden. Darüber hinaus ist es unmöglich, diese Knoten zu bestrafen (selbst wenn es möglich wäre, sie zu identifizieren), da dies drastische Maßnahmen wie das Verbrennen oder Zerstören von Mining-Hardware erfordern würde. Während die Gefahr, dass der Token der Merge-Mining-Kette aufgrund von Angriffen auf ihre Sicherheit an Wert verliert, ausreichen mag, um byzantinisches Verhalten abzuschrecken, haben böswillige Miner weniger zu verlieren, da der Wert der ursprünglichen Kette (z. B. Bitcoin) wahrscheinlich nicht beeinträchtigt wird. Moderne Konzepte gemeinsamer Sicherheit haben sich nicht nur dahingehend weiterentwickelt, dass sie nachvollziehbare Sicherheit beinhalten, sondern auch eine andere Anlageeinheit – Kapital – als Grundlage gemeinsamer Sicherheit verwendet. In diesem Design gibt es ein Basisprotokoll, das Sicherheit für andere darauf aufbauende PoS-Protokolle bietet. Knoten treten zunächst dem primären Netzwerk bei (indem sie den nativen Token des Netzwerks als Einsatz sperren), bevor sie an der Sicherung des sekundären Netzwerks teilnehmen. Dieser Entwurf kann verschiedene Formen annehmen: Validierer nehmen am Primär- und Sekundärnetzwerk teil gleichzeitig Eine Teilmenge von Validierern (aus dem primären Netzwerk) wird nach dem Zufallsprinzip ausgewählt, um das sekundäre Netzwerk zu validieren und zu sichern Das sekundäre Netzwerk wird durch einen unabhängigen Satz von Validierern gesichert, die an das primäre Netzwerk gebunden sind Validatoren aus dem primären Netzwerk delegieren das eingesetzte Kapital an Validatoren im sekundären Netzwerk weiter. Unabhängig von den Implementierungsdetails ist das entscheidende Detail für die oben beschriebenen gemeinsamen Sicherheitsschemata, dass das Basisprotokoll die Möglichkeit haben muss, Validierer zu bestrafen, die im sekundären Netzwerk böswillig agieren. Da für die Sicherung des sekundären Netzwerks weniger Kapital zur Verfügung steht, ist die Möglichkeit einer böswilligen Supermehrheit, die das Protokoll kapert, ein echtes Problem. Die Lösung besteht darin, sicherzustellen, dass ein oder mehrere ehrliche Teilnehmer (die die Minderheit bilden) die Mehrheit zur Verantwortung ziehen können, indem sie einen Streitfall anzetteln und Beweise für protokollverletzendes Verhalten an die Basisschicht übermitteln. Wenn das Basisprotokoll (das als „Richter“ fungiert) diese Beweise akzeptiert, können die unehrlichen Parteien bestraft werden, indem die Sicherheiten (die als Kaution hinterlegt werden) im primären Netzwerk gekürzt werden. Wichtig ist, dass die Basisschicht nur die bereitgestellten Beweise überprüfen muss und keinen zusätzlichen Konsens herstellen muss, bevor Streitigkeiten beigelegt werden – was den Koordinationsaufwand reduziert. Der subtilere Punkt ist, dass Fehlverhalten einer Partei werden muss, damit Slashing-Mechanismen wirksam sind. In PoS-basierten Netzwerken müssen Validierer ein öffentliches und privates Schlüsselpaar generieren, das als eindeutige kryptografische Identität innerhalb des Konsensprotokolls dient. Bei Routineaufgaben, wie dem Vorschlagen von Blöcken oder dem Bestätigen (der Gültigkeit von) Blöcken, signiert ein Validierer die Blockdaten mit seinem privaten Schlüssel – und bindet sie damit effektiv an diese Wahl. zugeschrieben Dadurch ist es möglich, einen Validator für verschiedene Aktionen zu kürzen, die als Angriff auf die Sicherheit oder Aktivität des Protokolls (oder in manchen Fällen beides) ausgelegt werden könnten: Unterzeichnung zweier widersprüchlicher Blöcke im selben Zeitraum (früher als „Zweideutigkeit“ bezeichnet) Signieren eines ungültigen Blocks (ob während eines Vorschlags oder einer Beglaubigung) Zensur einer oder mehrerer Transaktionen Einige oder alle Teile der Daten eines Blocks ausblenden Während die ersten beiden Verstöße auf dieselbe Weise erkannt werden können (durch Wiederherstellung des öffentlichen Schlüssels eines Validierers aus seiner Signatur), sind für die letzten beiden andere Mechanismen wie und erforderlich. In allen Fällen ermöglicht der Einsatz von Kryptografie die zuverlässige Erkennung und Bestrafung böswilligen Verhaltens, das bestimmte gewünschte Sicherheitseigenschaften eines Protokolls beeinträchtigen könnte – wie etwa die Zensurresistenz und die Gültigkeit von Transaktionen. Dies liefert einen gewissen Kontext zur Bedeutung von „kryptoökonomischer Sicherheit“, bei der es darum geht, kryptografische Mechanismen mit wirtschaftlichen Anreizen zu kombinieren, um dezentrale Netzwerke abzusichern. Aufnahmelisten Löschcodes Wir können diese Idee veranschaulichen – und sie mit Merge-Mining vergleichen – indem wir das Beispiel einer neuen PoS-Blockchain verwenden, die die gleiche Sicherheit wie Ethereum hat. Unser Spielzeugprotokoll hat die folgenden Eigenschaften (beachten Sie, dass dies ein zu vereinfachtes Beispiel ist, das zu Illustrationszwecken verwendet wird): Knotenbetreiber müssen eine bestimmte Menge an ETH-Token als Sicherheit in einem Ethereum-Smart-Contract hinterlegen, bevor sie sich als Validierer im PoS-Netzwerk registrieren. Während der Epochen übermitteln Block-Vorschläger im PoS-Protokoll Hashes von Block-Headern (die Signaturen von Validierern enthalten) an Ethereum, indem sie diese in einem Smart Contract speichern. Die Sicherheit basiert auf – die übergeordnete Kette (Ethereum) überprüft keine Zustandsübergänge, kann jedoch ein Gegenbeispiel überprüfen, das zeigt, dass ein bestimmter Zustandsübergang ungültig ist. Betrugsnachweisen Ein On-Chain-Slashing-Mechanismus wird aktiviert, wenn ein bestimmter Zustandsübergang von einer oder mehreren Parteien bestritten wird. Nehmen wir nun an, dass eine böswillige Mehrheit von Knoten im sekundären Netzwerk zusammenarbeitet, um einen ungültigen Block abzuschließen und so die im Bridge-Vertrag hinterlegten Gelder zu stehlen. In diesem Szenario würde ein ehrlicher Validierer den On-Chain-Slashing-Mechanismus auf Ethereum auslösen, indem er einen Betrugsnachweis veröffentlicht und protokollverletzende Validierer identifiziert. Wenn die Protokollregeln das Slashing des gesamten Einsatzes eines Validierers zulassen, sind die Kosten für die Manipulation der PoS-Kette proportional zum von der Mehrheit der Validierer eingesetzten Betrag. Dieses Beispiel zeigt, wie verantwortliche Sicherheit gemeinsame Sicherheitsdesigns untermauert und es effektiv ermöglicht, kleinere Netzwerke durch größere Protokolle zu sichern, die eine erhebliche wirtschaftliche Sicherheit aufgebaut haben und ein höheres Maß an Dezentralisierung und Vertrauenslosigkeit aufweisen. Wir können auch sehen, dass Proof-of-Stake-Mechanismen zu gemeinsamen Sicherheitsdesigns mit stärkeren Sicherheitsvorstellungen führen als Merge-Mining (das Rechenleistung als Grundlage für wirtschaftliche Sicherheit verwendet). Darüber hinaus wird die Idee eines neuen Protokolls eingeführt, das den Token eines anderen Netzwerks zum Staking verwendet, um das „Bootstrapping-Problem“ zu mildern (bei dem ein neues Blockchain-Protokoll eine geringe wirtschaftliche Sicherheit aufweist, weil sein Token nicht genügend Wert erworben hat). Während das Bootstrapping-Problem mit Ansätzen – wie Merge-Mining – gelöst werden kann, die Hardware-Investitionen als Einheit der wirtschaftlichen Sicherheit verwenden, ist diese Art der gemeinsamen Sicherheit aus bestimmten Gründen (von denen wir einige bereits zuvor identifiziert haben) nicht optimal: Kapitalinvestitionen – die bei böswilligem Verhalten erhebliche Kosten verursachen sollen, um Knoten zu validieren – sind und lassen sich nur schwer für die wirtschaftliche Sicherheit nutzen. Kapitalinvestitionen im Fall von PoW-Merge-Mining explizit zu machen, würde drastische Maßnahmen erfordern, wie etwa die Zerstörung von Mining-Hardware im Falle eines wahrscheinlich böswilligen Verhaltens, was in realen Situationen unrealistisch und schwer zu nutzen ist. implizit Merge-Mining (oder jedes gemeinsame Sicherheitsdesign, bei dem die Teilnahme am Konsens an die laufende Infrastruktur gebunden ist) ist schwer zu skalieren. Beispielsweise gibt es eine Obergrenze dafür, wie viele PoW-Ketten gleichzeitig zusammengeführt werden können, bevor der ROI eines Miners zu sinken beginnt. Im Gegensatz dazu verfügen PoS-basierte gemeinsame Sicherheitssysteme, die Kapitalinvestitionen als Investitionseinheit verwenden, über bestimmte Eigenschaften, die für die effiziente und effektive Lösung des Problems des Bootstrappings neuer Netzwerke nützlich sind: Kapitalinvestitionen sind explizit (Staker investieren Kapital in den Kauf von Token, um die Anforderungen für Sicherheiten zu erfüllen) und können für starke und konkrete Garantien für wirtschaftliche Sicherheit genutzt werden. Beispielsweise lässt sich leicht veranschaulichen, dass ein Protokoll wahrscheinlich sicherer ist, wenn ein Einsatz im Wert von 1 ETH Transaktionen im Wert von 0,9 ETH sichert, als wenn ein Einsatz im Wert von 0,9 ETH Transaktionen im Wert von 1 ETH sichert. Da die Teilnahme am Konsens an eine „reine“ Kapitalinvestition gebunden ist, ist es einfacher, die wirtschaftliche Sicherheit zu skalieren und mehrere Protokolle durch Validierer absichern zu lassen, ohne dass ein übermäßiger Koordinierungsaufwand entsteht (insbesondere bei geringen Hardwareanforderungen). Dennoch hat jeder Ansatz Nachteile und Shared Security via Staking ist hier keine Ausnahme. So ist es beispielsweise schwierig zu bestimmen, wie viel Sicherheit Validierer in ein PoS-Protokoll einzahlen sollten. Wir werden dies in einen Kontext setzen, indem wir diese Aussage aus dem vorhergehenden Absatz betrachten: „ “ Es ist leicht vorstellbar, dass ein Protokoll wahrscheinlich sicherer ist, wenn ein Einsatz im Wert von 1 ETH Transaktionen im Wert von 0,9 ETH absichert, als wenn ein Einsatz im Wert von 0,9 ETH Transaktionen im Wert von 1 ETH absichert. Diese Aussage klingt zwar vernünftig, doch bei genauerer Analyse wird deutlich, wie schwierig es ist, die optimale Anleiheanforderung zu wählen: Die Forderung nach 1 ETH von Validierern zur Absicherung von Vermögenswerten im Wert von 0,9 ETH verringert die Kapitaleffizienz und führt zu einer Überbesicherung. Die Absicherung von Transaktionen im Wert von 2 ETH mit einem Einsatz im Wert von 1 ETH verringert (oder den „Hebeleffekt“) in einer PoS-Blockchain und führt zu einer Unterbesicherung. die wirtschaftliche Bandbreite Im Idealfall würde ein Protokollentwickler es vorziehen, dass 1 ETH Einsatz Transaktionen im Wert von 1 ETH absichert. Solche Gleichgewichte sind jedoch unter realen Bedingungen aus verschiedenen Gründen schwer zu erreichen; beispielsweise ist die Menge des pro Zeiteinheit abzusichernden Kapitals (eine Funktion des Grenzwerts der Transaktionen pro Block/Epoche) dynamisch. Dies macht die Festlegung der idealen Bindung in einem PoS-System zu einem sehr schwierigen Mechanismusproblem und zu einer wichtigen Überlegung für einsatzbasierte gemeinsame Sicherheitssysteme wie Restaking (das wir im nächsten Abschnitt besprechen). Gemeinsame Sicherheit durch Restaking und Checkpointing Neu abstecken Restaking hat seinen Ursprung in – einer Praxis im traditionellen Finanzwesen, bei der ein Kreditgeber Vermögenswerte (die zuvor von einem Kreditnehmer als Sicherheit verpfändet wurden) als Sicherheit für einen neuen Kredit verwendet. Dabei übernimmt die neue Gegenpartei Rechte an dem ursprünglichen als Sicherheit dienenden Vermögenswert, sodass das Unternehmen, das den neuen Kredit aufgenommen hat, den Vermögenswert versteigern kann, um die Mittel zurückzuerhalten, falls es mit der Rückzahlung in Verzug gerät. der Weiterverpfändung Bei richtiger Umsetzung kann die Weiterverpfändung sinnvoll sein. Zunächst einmal ermöglicht sie eine höhere Kapitaleffizienz und Liquidität durch die Wiederverwendung von Vermögenswerten, die sonst brachliegen würden, um kurzfristige Finanzierungen für gewinnbringende Aktivitäten zu sichern. Wenn der Gewinn aus der Aufnahme eines Kredits den Wert der weiterverpfändeten Sicherheiten übersteigt, profitieren alle Beteiligten (der ursprüngliche Kreditnehmer, der Kreditgeber und der Kreditgeber des Kreditgebers). Die Weiterverpfändung birgt ein hohes Risiko (ein Grund, warum diese Praxis bei TradFi-Institutionen weitgehend in Ungnade gefallen ist), insbesondere für den ursprünglichen Kreditnehmer, der im Falle einer Liquidation möglicherweise die Rechte an seinem Vermögenswert verliert. Auch der Kreditgeber, der Sicherheiten weiterverwendet, birgt Risiken, insbesondere dann, wenn er Kreditnehmer zurückzahlen muss, nachdem eine neue Gegenpartei hinterlegte Sicherheiten aufgrund von Kreditausfällen konfisziert hat. Das andere Risiko haben wir bereits kurz beschrieben und dreht sich um den Kompromiss zwischen Über- und Unterbesicherung. Wenn Bank B (Johns Bank) im zuvor hervorgehobenen Beispiel eine übermäßige Fremdkapitalquote einnimmt – also mehr leiht als Johns Sicherheiten wert sind – und einen Verlust erleidet, wird es schwierig, den Kredit von Bank B zurückzuzahlen (oder Johns Vermögenswerte zurückzugeben). Bank B kann sich gegen diesen Grenzfall schützen, indem sie Bank A (Johns Bank) auffordert, weniger zu leihen als Johns Sicherheiten wert sind. Dies erhöht jedoch die Kapitalineffizienz für Bank A und verringert von vornherein die Gewinne aus der Weiterverpfändung von Johns Sicherheiten. Dieselben Vor- und Nachteile gelten auch für das Restaking. Bevor wir fortfahren, ist es wichtig, ein wichtiges Detail zu klären: Der Einsatz eines Restakings durchläuft immer zuerst das Basisprotokoll. Beispielsweise muss ein Restaking-Teilnehmer auf Ethereum entweder 32 ETH in den Beacon Chain-Vertrag einzahlen oder ETH an einen Validator delegieren, der von einem Staking-Dienst betrieben wird – je nachdem, ob oder verwendet wird. natives Restaking Liquid Restaking Auf hoher Ebene umfasst das Restaking im Fall von Ethereum Folgendes: #1: Dem Restaking-Protokoll Eigentumsrechte (oder einen Anspruch) an eingesetzten ETH geben Beim nativen Restaking muss ein Validator seine Auszahlungsadresse in einen Smart Contract ändern, der vom Restaking-Protokoll verwaltet wird. Anstatt dass die Gelder also nach dem Verlassen der Beacon Chain direkt an den Validator gehen, durchläuft der Einsatz zuerst das Restaking-Protokoll, bevor er zum Validator gelangt (wir werden bald sehen, warum das so ist). Es ist auch möglich, fungible Darstellungen (Derivate) von eingesetztem ETH in den Smart Contracts des Restaking-Protokolls zu hinterlegen (Liquid Restaking). Diese sogenannten „Liquid Staked Tokens“ werden von Staking-as-Service-Betreibern (z. B. RocketPool, Lido, Coinbase usw.) ausgegeben und stellen einen Anspruch auf einen Teil des von einem Validierer eingesetzten ETH dar (einschließlich des Ertrags aus Belohnungen) und können im Verhältnis 1:1 gegen native ETH-Tokens eingelöst werden. #2: Zustimmung zu zusätzlichen Kürzungsbedingungen, die durch das Restaking-Protokoll erzwungen werden Ein Restaking-Protokoll fungiert normalerweise als „Middleware“, an die sich verschiedene dezentrale Netzwerke und Anwendungen zur wirtschaftlichen Sicherheit anschließen können. Dazu gehören normalerweise Protokolle, die eine Art Validierung durch eine Reihe von Parteien erfordern – beispielsweise ein Oracle-Netzwerk –, deren natives Token jedoch nicht genügend Wert angesammelt hat, um in einer Proof of Stake-Umgebung verwendet zu werden. Anstatt einen neuen Validator-Satz von Grund auf neu zu erstellen, können solche Anwendungen die Dienste vorhandener Validatoren über ein Restaking-Protokoll in Anspruch nehmen. Die Dienste können einzigartige Slashing-Bedingungen für die Sicherheiten eines Validators festlegen – die das Restaking-Protokoll durchsetzen kann, da es nun die Auszahlung des Validators kontrolliert – und so die Hürde für die wirtschaftliche Sicherheit senken. erneut verpfändeten Ein wichtiger Hinweis: Die AVS-Slashing-Bedingungen sind unabhängig von den Slashing-Bedingungen, die durch den Beacon-Chain-Konsens von Ethereum erzwungen werden. Der ETH-Anteil eines Validierers könnte also gekürzt werden, auch wenn er bei Ethereum selbst kein slashing-fähiges Vergehen begangen hat. Dies könnte zu dem führen, was wir als „Risikostapelung“ bezeichnen: Im Gegenzug für eine höhere Kapitaleffizienz erbt das primäre Netzwerk ein zusätzliches Risiko, als es sonst der Fall wäre. (Die Risikostapelung hat auch Auswirkungen auf das Kernprotokoll von EigenLayer selbst, wie wir später sehen werden.) #3: Zusätzliche Belohnungen erhalten Das Restaking erfordert die Übernahme eines erheblichen Risikos (z. B. kann ein erneut eingesetzter Validator aufgrund eines Fehlers im On-Chain-Slashing-Mechanismus versehentlich gekürzt werden). Aber genau wie die Weiterverpfändung Liquidität in TradFi freisetzt, kann das Restaking die Kapitaleffizienz in PoS-Ökosystemen verbessern und überdurchschnittliche Renditen für Staker generieren. Dies beruht auf der Tatsache, dass Dienste, die für die Sicherheit neu eingesetztes Kapital verwendet haben, Validierer für ihre Dienste belohnen müssen. Ein neu eingesetzter Validierer, der an einem Oracle-Netzwerk teilnimmt, erhält beispielsweise Gebühren für die Validierung von Oracle-Updates – wobei die Zahlung von anderen Drittanbieteranwendungen kommt, die auf die Dienste des Oracles angewiesen sind. Da Validierer weiterhin Belohnungen von der Beacon Chain erhalten, ermöglicht das Restaking das Erzielen von Einnahmen aus mehreren PoS-Protokollen, ohne dass frisches Kapital in ein neues Ökosystem umgeschichtet werden muss. Obwohl wir uns in diesem Beispiel auf das Ethereum-Restaking konzentrieren, haben auch andere Proof of Stake-Protokolle Varianten des Restakings implementiert, um ähnliche Ziele zu erreichen (Senkung der Kosten für die Einführung neuer Protokolle/Anwendungen, Verbesserung der Kapitaleffizienz und Skalierung der wirtschaftlichen Sicherheit). Tatsächlich befasst sich der nächste Abschnitt mit EigenLayer – dem führenden Restaking-Protokoll von Ethereum –, bevor das Restaking in anderen Ökosystemen beleuchtet wird: EigenLayer EigenLayer ist ein Restaking-Protokoll, das entwickelt wurde, um die wirtschaftliche Sicherheit von Ethereum zu erweitern und neue verteilte Anwendungen, Netzwerke und Protokolle (die zusammenfassend als „Actively Validated Services“ oder kurz AVSs bezeichnet werden) abzusichern. Wenn Sie den vorherigen Abschnitt mit dem Beispiel des Restakings auf Ethereum gelesen haben, dann verstehen Sie die Vorgänge von EigenLayer bereits auf hohem Niveau. Wir werden jedoch noch einige weitere Details zum Kontext hinzufügen. Nach dem erneuten Staking von ETH (indem die mit einem Validator verbundenen Auszahlungsdaten auf von EigenLayer kontrollierte Smart Contracts verweisen) muss ein Validator Aufgaben ausführen, die von dem AVS, das er betreiben möchte, festgelegt wurden. Wenn es sich bei einem AVS beispielsweise um eine Sidechain handelt, muss der erneut eingesetzte Validator Client-Software für die Sidechain ausführen, um Transaktionen auszuführen und Blöcke zu verifizieren, und gleichzeitig Belohnungen für die korrekte Ausführung dieser Aufgaben erhalten. Im weiteren Sinne können die Aufgaben je nach Art des AVS variieren: Speicherung von Daten in einem Datenverfügbarkeitsnetzwerk Genehmigen von Einzahlungs- und Auszahlungstransaktionen für eine Cross-Chain-Brücke oder Genehmigen von Nachrichten für ein Cross-Chain-Messaging-Protokoll Generieren und Überprüfen von Zero-Knowledge-Beweisen für eine datenschutzorientierte Anwendung oder ein abgeschirmtes Zahlungsnetzwerk Speichern und Überprüfen von Blockheadern und Ausführen von Relayern/Orakeln für kettenübergreifende Interoperabilitätsprotokolle Aufmerksamen Lesern werden zwei Dinge auffallen: (a) Die von einem AVS angegebenen Aufgaben können recht beliebig sein (b) verschiedene von AVS angegebene Aufgaben erfordern unterschiedliche Investitionen und Anstrengungen. Um den letzten Punkt zu veranschaulichen, kann man sich vorstellen, dass das Speichern von Blockheadern in einem Cross-Chain-Protokoll weniger Festplatten-/Speicherplatz erfordert als das Speichern und Bereitstellen von Daten in einem Datenverfügbarkeitsnetzwerk (selbst wenn Techniken wie die Speicherlast einzelner Knoten verringern). das Datenverfügbarkeits-Sampling Dies ist ein Grund, warum EigenLayer es Validierern mit erneutem Einsatz ermöglicht, die Ausführung von AVS-spezifizierten Aufgaben an Partei (einen Betreiber) zu delegieren, die die vom AVS verdienten Belohnungen mit dem Validierer teilt. Dieser Ansatz birgt für Validierer mit erneutem Einsatz unterschiedliche Risiken, je nachdem, in welchem Ausmaß die Last des Slashings – was passieren kann, wenn der Betreiber AVS-Aufgaben nicht korrekt ausführt – zwischen dem Validierer mit erneutem Einsatz und dem Drittbetreiber aufgeteilt wird. eine andere Jeder AVS gibt eine Reihe von Bedingungen an, unter denen der Anteil eines EigenLayer-Restakers gekürzt werden kann. Beispielsweise kann ein Datenverfügbarkeitsnetzwerk, das Proof of Space/Storage-Mechanismen implementiert, Operatoren kürzen, die Daten nicht für die vereinbarte Dauer speichern. Das Kürzen führt zum Einfrieren des Operators innerhalb von EigenLayer – was eine weitere Teilnahme an einem oder mehreren aktiv validierten Diensten verhindert – und schließlich zur Reduzierung des ETH-Guthabens des Validierers. Damit ein Slashing erfolgen kann, muss das Vergehen nachweisbar sein – was es dem Basisprotokoll (in diesem Fall Ethereum) ermöglicht, Streitigkeiten zu schlichten und die unehrliche Partei zu bestrafen. Das aktuelle Design von Ethereum erlaubt ein Slashing von bis zu 50 % des Einsatzes eines Validators (16 ETH), was EigenLayer das Recht einräumt, die verbleibenden 50 % (16 ETH) zu kürzen, falls ein Operator bei der Ausführung von Aufgaben gegen die vom AVS festgelegten Regeln verstößt. Die Slashing-Mechanismen von EigenLayer deuten auch auf ein subtiles Risiko des Restaking hin: Wenn ein Validator von einem Dienst geslasht wird, verringert sich das Gesamtguthaben in EigenLayer-Smart Contracts und der Beacon Chain von Ethereum. Wichtig ist jedoch, dass ein Grenzfall auftritt, wenn das Slashing aufgrund eines Fehlers in der Slashing-Logik eines bestimmten AVS und nicht als Folge eines nachweisbaren Verstoßes erfolgt. In diesem Fall würde der Verlust der Belohnungen aus der Validierung der Haupt-Ethereum-Kette – die höher sein dürften als die Belohnungen aus der Validierung des AVS – den ROI aus dem Restaking aus Sicht eines Validators suboptimal machen. Ein weiteres Risiko bei der Weiterverpfändung im EigenLayer-Stil betrifft das Risiko einer Über- und Unterbesicherung des Validators und das Konzept der Risikostapelung. Aus dem vorherigen Beispiel der Weiterverpfändung geht hervor, dass die Partei, die die Sicherheiten weiterverpfändet, gleichzeitig dem ersten Kreditnehmer (dessen Sicherheiten zur Aufnahme eines neuen Kredits verwendet werden) und dem letzten Kreditgeber in der Kette (der einen Anspruch auf die vom ursprünglichen Kreditnehmer verpfändeten Sicherheiten hat) etwas schulden kann. Eine ähnliche Dynamik kann sich bei Restaking-Konstruktionen wie EigenLayer abspielen, wenn ein erneut eingesetzter Validator (absichtlich oder absichtlich) gleichzeitig Slash-Verstöße auf Ethereums Beacon Chain und einem oder mehreren AVSs begeht. Je nachdem, wo das erste Slashing erfolgt, haben andere AVSs möglicherweise keinen Einsatz mehr zum Slashen – was effektiv einen risikolosen Angriff auf durch EigenLayer gesicherte Anwendungen ermöglicht. Das EigenLayer-Team hat diesen Angriffsvektor erkannt (siehe Anhang B: Kryptoökonomische Risikoanalyse des ) und mehrere Schritte unternommen, um dieses Risiko anzugehen. Dazu gehört die Bereitstellung einer formalen Heuristik zur Bewertung der Unter- und Überbesicherung von Stakern in AVSs sowie die Ankündigung von Plänen, AVS-Entwicklern beim Start über ein Risikomanagement-Dashboard Beratungsinformationen bereitzustellen. EigenLayer-Whitepapers Polkadot-Fallschirmketten Obwohl vor allem dafür bekannt ist, die Interoperabilität zwischen heterogenen Blockchains zu ermöglichen, verlässt es sich stark auf gemeinsame Sicherheit. Tatsächlich ist die gemeinsame Sicherheit der Grund, warum verschiedene Ketten im Ökosystem von Polkadot Nachrichten austauschen können, ohne Vertrauensannahmen einzuführen oder Sicherheitsrisiken einzugehen. Polkadot Auf Polkadot werden Teilmengen von Validierern (die DOT-Token auf der Relay Chain eingesetzt haben) zufällig Parachains (man denke an „Child Chains“) zugewiesen, um Blöcke – und den zugehörigen Proof of Validity (PoV) – zu verifizieren, die vom Collator jeder Parachain erstellt werden. Ein Collator ist der Knoten, der für die Ausführung der Transaktionen einer Parachain verantwortlich ist und einen „Parablock“ erstellt, der zur Verifizierung an die Validierergruppe der Parachain gesendet wird. Da die Überprüfung des PoV eines Blocks rechenintensiv ist, erhalten Paravalidatoren (so heißen die einer Parachain zugewiesenen Validatoren) für diese Aufgabe zusätzliche Belohnungen. Von Paravalidatoren genehmigte Blöcke – oder genauer gesagt kryptografische Verpflichtungen gegenüber diesen Blöcken – werden zur Aufnahme in die Relay Chain (denken Sie an die „Elternkette“) gesendet. Ein Parachain-Block wird endgültig, wenn ein Block, der auf ihn verweist, von einer Mehrheit der verbleibenden Validatoren der Relay Chain genehmigt wird. Der letzte Punkt ist ziemlich wichtig: Da die Anzahl der Validierer auf jeder Parachain gering ist (etwa fünf Validierer pro Shard), sind die Kosten für die Manipulation einzelner Shards gering. Um sich gegen solche Angriffe zu schützen, erfordert das Polkadot-Protokoll, dass Parablöcke einer zweiten Prüfung durch eine weitere Gruppe zufällig ausgewählter Knoten unterzogen werden. Wenn sich ein Block als ungültig oder nicht verfügbar erweist (d. h. ein Teil der Daten fehlt), können ehrliche Knoten einen Streitfall in der Haupt-Relay-Chain initiieren, bei dem Validierer der Relay-Chain den umstrittenen Block erneut ausführen müssen. Ein Streitfall endet, nachdem eine Zwei-Drittel-Mehrheit der Validierer für eine der beiden Seiten des Streitfalls gestimmt hat. Die betreffenden Validierer werden in der Chain gekürzt, wenn die erneute Ausführung den Kürzungsanspruch unterstützt. alle Dieser Mechanismus stellt sicher, dass alle Parachains im Polkadot-Protokoll das gleiche Sicherheitsniveau aufweisen, unabhängig von der Größe des auf jedem Shard festgelegten Validators. Darüber hinaus beziehen Parachains ihre Sicherheit aus derselben Quelle (alle Parablöcke werden von der Relay Chain genehmigt) und können der Gültigkeit von Nachrichten vertrauen, die von einem Remote-Shard stammen (ohne unbedingt Einzelheiten zum Konsens oder Status des letzteren zu kennen). Interchain-Sicherheit Die Interchain-Sicherheit wurde als Cosmos‘ Antwort auf Restaking beschrieben und weist Ähnlichkeiten mit dem gemeinsamen Sicherheitsmodell von Polkadot auf. Ähnlich der Beziehung zwischen der Relay Chain und den Parachains auf Polkadot verwendet ein Hub-and-Spoke-Modell, bei dem mehrere Chains („Cosmos Zones“) mit einer Hauptchain (dem „Cosmos Hub“) verbunden sind und von dieser Sicherheit ableiten. Auch die Logik ist ähnlich wie bei Polkadot: Neue Chains sollen sicher bleiben, ohne dass ein zuverlässiger Validator-Satz von Grund auf neu erstellt werden muss (eine ziemlich schwierige Aufgabe), und stattdessen die wirtschaftliche Sicherheit – gebündelt auf einer einzigen Ebene – mit anderen Chains teilen. Cosmos In der aktuellen Version erfordert die Interchain-Sicherheit einen Validator (der ATOM-Token eingesetzt hat), der sowohl den Cosmos Hub als auch alle damit verbundenen Verbraucherketten validiert. Ein Validator, der böswillig auf eine Verbraucherkette einwirkt, riskiert, seinen Anteil an der Anbieterkette (in diesem Fall den Cosmos Hub) durch Slashing zu verlieren. Um einen fehlerhaften Validator zu streichen, muss normalerweise ein Paket mit Beweisen für streichbares Verhalten über den IBC-Kanal (Inter-Blockchain Communication) zwischen der Anbieterkette und der Verbraucherkette weitergeleitet werden. Interchain-Sicherheit kann daher als eine Form des Restakings angesehen werden. Darüber hinaus wird damit ein wichtiges Ziel erreicht: die Einführung anwendungsspezifischer Blockchains im Cosmos-Ökosystem wird erleichtert. Bisher mussten Projekte, die versuchten, souveräne Blockchains zu erstellen, ein natives Token für das Staking erstellen und eine ausreichende Anzahl von Validierern anziehen, um neuen Benutzern ein Mindestmaß an Sicherheit zu bieten. Die Interchain-Sicherheit stellt jedoch sicher, dass die Sicherheit des Cosmos Hub (der zum Zeitpunkt des Schreibens durch einen Einsatz von ca. 2,5 Milliarden US-Dollar gesichert war) skaliert werden kann, um neuere Ketten mit geringem Wert zu sichern, ohne die Größe des vorhandenen Validierer-Sets von Cosmo erweitern zu müssen. : . Hinweis Die aktuelle Version von Cosmos Interchain Security deaktiviert Slashing, das ausschließlich auf Paketen basiert, die von Verbraucherketten weitergeleitet werden, da das Risiko besteht, dass Schadcode in einer Verbraucherkette die Übertragung gefälschter Slash-Pakete auslöst und ehrliche Validierer slasht. Stattdessen unterliegen Verstöße wie Doppelvoting (Signieren von zwei Blöcken auf derselben Höhe) dem Social Slashing durch Governance. Social Slashing bringt jedoch seine eigenen Risiken mit sich, wie die zeigt (die auch auf einige der Komplexitäten beim Aufbau gemeinsamer Sicherheitsprotokolle hinweist) jüngste Debatte über Slashing von Validierern für Doppelsignierung in einer Verbraucherkette ist eine Alternative zur Interchain-Sicherheit und versucht, einige der Mängel der letzteren zu beheben. Anstatt Software sowohl für Anbieter- als auch für Verbraucherketten auszuführen, kann ein Validator, der auf der Anbieterkette eingesetzt ist, den Einsatz an einen Validator auf der Verbraucherkette delegieren. Dies verringert die Last, zwei Ketten gleichzeitig validieren zu müssen – an Governance und Konsens teilzunehmen – und reduziert den Aufwand für erneut eingesetzte Validatoren (z. B. durch Reduzierung der Hardwareanforderungen). Mesh-Sicherheit Genau wie bei EigenLayer (wo ein Ethereum-Validator einen Operator ein oder mehrere sekundäre Protokolle (AVSs) in seinem Namen validieren lassen kann) muss ein keinen Einsatz bei der Validierung der Verbraucherkette leisten. Wenn der delegierte Validator seine Aufgaben nicht korrekt ausführt (z. B. Ausfallzeiten hat oder ungültige Blöcke erstellt/für sie stimmt), wird der gemäß den Regeln des Protokolls in der Verbraucherkette gekürzt. delegierter Validator Delegator Mesh-Sicherheit unterscheidet sich auch von Interchain-Sicherheit, da sie es Verbraucherketten ermöglicht, Sicherheit von mehreren Anbieterketten zu leasen (anstatt auf den Cosmos Hub beschränkt zu sein) und es Validierern ermöglicht, auszuwählen, an welche Ketten sie den Anteil delegieren. Während letztere Funktion als Teil der ICS v2-Einführung geplant ist, ist es unwahrscheinlich, dass erstere implementiert wird (obwohl sie wohl überzeugender ist). Ethereums Sync-Komitee von Ethereum ist eine Gruppe von 512 Validierern, die für die Freigabe der finalisierten Beacon-Blockheader verantwortlich sind. Alle 256 Epochen (ungefähr 27 Stunden) wird ein neues Sync Committee gebildet, dessen Mitglieder aus dem bestehenden Validierer-Set der Beacon Chain ausgewählt werden. Beachten Sie, dass von den Mitgliedern erwartet wird, dass sie während ihrer Teilnahme am Sync Committee weiterhin ihre regulären Validiereraufgaben (einschließlich Bescheinigung und Blockvorschläge) erfüllen. Das Sync Committee Das Sync Committee wurde erstmals während des Altair-Forks der Beacon Chain implementiert, um es Light Clients zu ermöglichen, neue Blöcke zu verifizieren (ohne den vollständigen Validator-Satz zu kennen) und Änderungen im Ethereum-Status zu verfolgen. Da die Teilnahme am Sync Committee mehr Aufwand erfordert als einfach nur am Beacon Chain-Konsens teilzunehmen, erhalten die Mitglieder eine kleine Belohnung (zusätzlich zu den regulären Belohnungen für die Erfüllung von Beacon Chain-Aufgaben). Mitglieder, die ungültige Blockheader abzeichnen, unterliegen jedoch nicht dem Slashing – anders als bei der Beacon Chain. Die Kernentwickler von Ethereum haben dieses Design verteidigt, indem sie sagten, dass das Slashing böswilliger Sync Committee-Mitglieder die Komplexität erhöhen würde, während andere auf die Schwierigkeit einer Absprache zwischen der ⅔-Supermehrheit der Sync Committee-Mitglieder hingewiesen haben (was nötig wäre, um Light-Clients dazu zu bringen, einen fehlerhaften Blockheader zu akzeptieren). Da aber hochwertige Anwendungen – wie etwa kettenübergreifende Kommunikationsprotokolle – auf Light-Clients angewiesen sind, um den Status von Ethereum zu verfolgen, hat das Thema Slashing von Sync-Komitees für das Signieren ungültiger Blockheader erneutes Interesse geweckt (vgl. ). Wenn Slashing umgesetzt würde, würde die Teilnahme am Sync-Komitee zu einer Art Restaking werden, bei dem die Validierer zusätzliche Slashing-Bedingungen akzeptieren und zusätzliche Belohnungen für die sekundäre Dienstleistung des Signierens von Blockheadern erhalten. einen laufenden Vorschlag des Nimbus-Clientteams Zur Veranschaulichung: Ein Validator könnte bis zu seinem maximalen Guthaben gekürzt werden, wenn er während seiner Mitgliedschaft im Sync Committee gegen Protokollregeln verstößt, selbst wenn er bei der Teilnahme am Konsens der Beacon Chain ehrlich handelt. Wir können das Sync Committee auch mit dem Parachain-System von Polkadot und anderen Formen gemeinsamer Sicherheit vergleichen, bei denen eine Teilmenge von Knoten zufällig ausgewählt wird, um ein Unterprotokoll innerhalb des größeren Blockchain-Netzwerks zu validieren (z. B. Lagrange State Committees, Avalanche Subnets und Algorands State Proofs-Protokoll). Prüfpunkte Gemeinsame Sicherheitsschemata, die auf Checkpointing basieren, beinhalten häufig, dass eine in regelmäßigen Abständen kryptografische Verpflichtungen zu ihrem neuesten Status an die sendet. Beispielsweise kann ein Blockvorschlagsgeber aufgefordert werden, den Hash des neuesten Blockheaders an die übergeordnete Kette zu senden, bevor dieser abgeschlossen wird. sicherheitsverbrauchende Kette sicherheitsbereitstellende Kette Diese Verpflichtungen werden als „Checkpoints“ bezeichnet, da die übergeordnete Kette die Unumkehrbarkeit der Geschichte der untergeordneten Kette bis zu diesem Punkt garantiert. Mit anderen Worten: Die übergeordnete Kette garantiert und erzwingt eine (kanonische) zeitliche Ordnung der untergeordneten Kette und schützt sie vor Versuchen, Blöcke neu zu organisieren und eine konfliktbehaftete Verzweigung zu erstellen (z. B. um alte Transaktionen rückgängig zu machen und eine Doppelausgabe durchzuführen). Die übergeordnete Kette kann auch die Gültigkeit der untergeordneten Kette garantieren, insbesondere wenn Blockheader Informationen darüber enthalten, wer einen bestimmten Block bestätigt/erstellt hat. Wenn sich ein Block als ungültig herausstellt, kann ein ehrlicher Knoten eine Herausforderung an die übergeordnete Kette starten (wobei die übergeordnete Kette den Streit schlichtet) und ein Rollback des Status der untergeordneten Kette auslösen. Wenn außerdem ein Mechanismus zur Verwaltung von Validator-Einsätzen (wie ein Smart Contract) in der übergeordneten Kette implementiert wird, wird es möglich, nachvollziehbare Sicherheit durchzusetzen, indem protokollverletzende Validatoren eliminiert werden, nachdem ein gültiger Betrugsnachweis in der Kette akzeptiert wurde. Dass die übergeordnete Kette die kanonische Historie der untergeordneten Kette garantiert, ist hier wichtig, da es verhindert, dass Knoten die Historie neu schreiben (durch Entfernen von Blöcken), um Beweise für böswilliges Verhalten zu verbergen. Commit-Sidechains (Polygon PoS), Optimiums (Arbitrum Nova/Metis), Rollups und mit Checkpointing-Protokollen wie integrierte Chains implementieren diese Form der gemeinsamen Sicherheit. In allen Fällen leitet ein Protokoll seine wirtschaftliche Sicherheit von einer externen Blockchain-Chain ab, indem es diese als Abwicklungsschicht verwendet (verantwortlich für die Finalisierung von Blöcken). Zum Kontext: Polygon PoS und Arbitrum Nova/Metis speichern Header in einem On-Chain-Vertrag auf Ethereum, während Babylon Header von verbundenen Cosmos Zones an Bitcoin streamt. Babylon verwenden einen ähnlichen Mechanismus (Posten von Blockwurzeln in der Layer-1-Blockchain), mit einem entscheidenden Unterschied: Die zum Neuerstellen der Blöcke eines Rollups erforderlichen Daten werden auch auf der Abwicklungsebene veröffentlicht. Dies bedeutet, dass die Abwicklungsebene die Sicherheit des Rollups (letztlich) vollständig garantiert. Im Gegensatz dazu sind die zum Rekonstruieren des Status einer Commit-Sidechain oder einer optimistischen Kette erforderlichen Daten möglicherweise nicht verfügbar – insbesondere im Fall eines bösartigen Sequenzer- oder Validator-Sets, das Datenzurückhaltungsangriffe durchführt. Layer-2-Rollups (L2) Gemeinsame Sicherheit für kettenübergreifende Interoperabilitätsprotokolle Nachdem wir nun ausführliche Hintergrundinformationen zur Bedeutung und Entwicklung gemeinsamer Sicherheit gegeben haben, können wir uns nun mit neuen Herausforderungen bei gemeinsamen Sicherheitsdesigns befassen. Ein solcher Forschungsbereich ist , die aktuelle Ansätze für Messaging und Überbrückung zwischen Blockchains verbessern soll, indem die Vorteile gepoolter (wirtschaftlicher) Sicherheit genutzt werden. die gemeinsame Sicherheit für kettenübergreifende Protokolle Diese Definition wirft beim Leser möglicherweise Fragen auf, wie etwa: Warum der explizite Fokus auf Interoperabilitätsprotokolle? Welche Vorteile ergeben sich für ein Interoperabilitätsprotokoll aus der Integration gemeinsam genutzter Sicherheitstechnologie? Lagrange Labs erstellt – eine gemeinsame Sicherheitslösung für Protokolle, die Zugriff auf vertrauensminimierte Beweise für kettenübergreifende Zustände erfordern. (State Committees kombinieren -Beweissystem von Lagrange und die Restaking-Infrastruktur von EigenLayer, um eine gemeinsame Sicherheitszone für kettenübergreifende Interoperabilitätsprotokolle zu erstellen.) Daher fühlen wir uns gezwungen, jede der vorherigen Fragen zu analysieren und dabei für die Integration von Bridging-, Indexierungs- und Messaging-Anwendungen in die State Committee-Infrastruktur zu plädieren. Lagrange State Committees das ZK Big Data Eine kurze Einführung in Interoperabilitätsprotokolle In haben wir erklärt, dass Interoperabilitätsprotokolle entscheidend sind, um isolierte Blockchains zu verbinden und Probleme rund um die Fragmentierung von Liquidität und Status für Blockchain-Anwendungen (und ihre Benutzer) zu mildern. Einige wichtige Beispiele, die in diesem Artikel erwähnt werden, sind: Interoperability For Modular Blockchains: The Lagrange Thesis Brücken, die Lock-and-Mint- oder Burn-and-Mint-Mechanismen implementieren und die Übertragung eines Vermögenswerts von einer nativen Blockchain (wo er ausgegeben wurde) zur Verwendung auf einer nicht-nativen Blockchain ermöglichen Messaging-Protokolle, die es Benutzern ermöglichen, Informationen sicher (über Datenpakete) zwischen Blockchains weiterzuleiten, die keine einzige Quelle der Wahrheit teilen und nicht in der Lage sind, den Zustand des jeweils anderen zu überprüfen. Wir haben auch den Wert verschiedener Arten von hervorgehoben. Beispielsweise ermöglichen Brücken den Benutzern, nahtlos zwischen verschiedenen Ökosystemen zu wechseln, mehr Anwendungen zu nutzen und die Effizienz von Vermögenswerten zu steigern (indem sie die renditegenerierenden Möglichkeiten nutzen, die auf anderen Blockchains bestehen). Messaging-Protokolle ermöglichen auch fortgeschrittenere Anwendungsfälle wie Cross-Chain-Lending, Cross-Chain-Arbitrage und Cross-Chain- und Cross-Chain-Margining, die auf der Übertragung von Informationen (z. B. Positionen und Schuldenprofile) zwischen verschiedenen Domänen basieren. Blockchain-Interoperabilitätslösungen Obwohl sie für unterschiedliche Zwecke entwickelt wurden, haben alle Interoperabilitätslösungen einige grundlegende Eigenschaften gemeinsam. Die wichtigste ist ein Mechanismus zur Überprüfung, ob bestimmte Informationen über die Blockchain(s), die an einer kettenübergreifenden Transaktion/Operation beteiligt sind – die vom Benutzer oder einer Anwendung bereitgestellt werden – wahr sind. Dies ist normalerweise eine Behauptung, dass ein bestimmter Status (z. B. im Speicher eines Smart Contracts gespeicherte Werte, der Kontostand oder der zuletzt abgeschlossene Block) vorliegt oder dass eine Transaktion auf einer anderen Kette stattgefunden hat. Nehmen wir das Beispiel einer Brücke zwischen Ethereum und NEAR. Der Betreiber der Brücke muss die folgenden Informationen über den Status jeder Kette validieren, wenn ein Benutzer eine Brücke für einen Vermögenswert (z. B. DAI) schlägt: Bevor NearDAI-Token an die NEAR-Adresse des Benutzers gesendet werden, benötigt der Brückenbetreiber einen Nachweis, dass der Benutzer DAI in den Vertrag der Brücke auf Ethereum eingezahlt hat. Vor der Freigabe der ursprünglichen DAI-Einzahlung (beim Überbrücken von NEAR zu Ethereum) benötigt der Brückenbetreiber einen Nachweis, dass der Benutzer NearDAI-Token auf NEAR verbrannt und die erforderliche „Proof-of-Burn“-Quittung an den Vertrag der Brücke auf NEAR gesendet hat. Ein Nachrichtenprotokoll zwischen den oben genannten Ketten hat ähnliche, aber leicht unterschiedliche Anforderungen. Wenn ein Ethereum-Benutzer die Ausführung einer kettenübergreifenden Transaktion anfordert („X-Vertrag auf NEAR aufrufen“), muss das Protokoll überprüfen, ob die Nachrichtenanforderung ursprünglich auf Ethereum gestellt wurde (normalerweise durch Aufruf eines On-Chain-Vertrags). Eine einfache Möglichkeit, Aussagen über Cross-Chain-Transaktionen zu validieren, besteht darin, einen vollständigen Knoten für die betreffende Kette auszuführen. Vollständige Knoten, die Transaktionen aus jedem Block herunterladen und erneut ausführen, bevor sie den neuesten Status der Kette synchronisieren, sind normalerweise die vertrauenswürdigste Methode, um Statusübergänge in einer Blockchain zu überprüfen. Das Ausführen eines vollständigen Knotens ist jedoch sowohl mühsam als auch unnötig; mühsam, weil vollständige Knoten hohe Hardwareanforderungen stellen, und unnötig, weil ein Cross-Chain-Protokoll nur Informationen benötigt, die für einige Sätze von Transaktionen und Verträgen relevant sind. Glücklicherweise bieten eine einfache/effektive Möglichkeit, Ereignisse und Statusänderungen zu verfolgen, ohne dass ein vollständiger Knoten ausgeführt werden muss. Sofern wir dem Design des Light-Clients vertrauen, können wir einfach Blockheader herunterladen, um bestimmte Informationen wie das Auftreten von Einzahlungen/Abhebungen in einer Bridge und den Status von Nachrichtenanforderungen/-ausführungen in einem Nachrichtenprotokoll zu überprüfen. Light-Clients Um die Kommunikation zwischen zwei Ketten zu ermöglichen – wir nennen sie Kette A und Kette B – würde ein Interoperabilitätsprotokoll einen Light-Client von Kette A auf Kette B ausführen, der Blockheader von Kette B speichert (und umgekehrt). Dadurch kann er verschiedene Status-/Speichernachweise (Blockheader, Merkle-Beweise usw.) überprüfen, die von Benutzern (oder Dritten) von einer Anwendung auf der Quellkette an eine andere Anwendung auf der Zielkette weitergegeben werden. Der Light-Client fungiert als Informationsquelle (ein „Orakel“) über die Zustände der beiden Blockchains, wie in der folgenden Abbildung dargestellt: Dieser Ansatz zur Überprüfung der Gültigkeit von Cross-Chain-Zuständen stößt jedoch auf das Problem des Vertrauens. Vitalik Buterins Artikel bietet eine präzise Definition von Vertrauen: „ “ Der Artikel definiert auch das Konzept der Vertrauenslosigkeit (mit einer Einschränkung): „Trust Models“ Vertrauen ist die Verwendung beliebiger Annahmen über das Verhalten anderer Menschen. Eine der wertvollsten Eigenschaften vieler Blockchain-Anwendungen ist Vertrauenslosigkeit: die Fähigkeit der Anwendung, weiterhin wie erwartet zu funktionieren, ohne sich darauf verlassen zu müssen, dass sich ein bestimmter Akteur auf eine bestimmte Weise verhält, selbst wenn sich seine Interessen ändern und ihn in Zukunft zu einem unerwarteten Verhalten zwingen könnten. Blockchain-Anwendungen sind nie völlig vertrauenslos, aber einige Anwendungen sind viel näher daran, vertrauenslos zu sein als andere. – Vitalik Buterin In unserem Kontext (Blockchain-Interoperabilität) wird Vertrauen unausweichlich, wenn der Zustand von zwei oder mehr Ketten unabhängig voneinander validiert wird. Stellen Sie sich ein Szenario vor, in dem Bobs Anwendung auf Kette A einen Nachweis erhält, dass Alice eine Nachricht initiiert hat („5 ETH auf Kette B sperren und 5 Wrapped ETH (WETH) auf Kette A prägen“). Der Nachrichtennachweis ist ein , der die Einbeziehung von Alices Transaktion in einen Block zeigt, was Bob – da er einen On-Chain-Light-Client für Kette B betreibt – überprüfen kann, indem er den Nachweis mit der Merkle-Wurzel von Transaktionen vergleicht, die aus dem Header eines gültigen Blocks von Kette B abgeleitet sind. Merkle-Beweis Allerdings kann „gültig“ im Kontext eines Blocks verschiedene Dinge bedeuten: (a) „Der Blockheader gehört zu einem Block, der von der Mehrheit der Validierer der Quellkette genehmigt wurde.“ (b) „Der Blockheader gehört zu einem Block, dessen Transaktionen gemäß den Transaktionsgültigkeitsregeln der Quellkette gültig sind.“ Bob kann Nr. 1 als konkreten Beweis für die Gültigkeit eines Blocks betrachten, dies basiert jedoch auf Annahmen über die Validierer in der Quellkette: „ “ Die Mehrheit der Validierer in Kette A ist ehrlich und würde einen Block mit einer oder mehreren ungültigen Transaktionen nicht genehmigen. „ “ Die Mehrheit der Validierer in Kette A sind ökonomisch rationale Akteure und haben geringe Anreize, einen Block mit ungültigen Transaktionen zu genehmigen. Hier ist leicht zu erkennen, wo eine (oder beide) dieser Annahmen nicht stimmen können. Wenn beispielsweise in Kette A (also der Betrag, der von einer Brücke durch betrügerische Transaktionen gestohlen werden kann) ist, haben die Validierer einen Anreiz, einen ungültigen Block abzuschließen – selbst wenn dies Kürzungen bedeutet –, da der Gewinn aus einem Angriff die Kosten übersteigt. die Höhe des Einsatzes < Wert der Transaktionen Im Allgemeinen unterliegt jeder Mechanismus zur Überprüfung von Cross-Chain-Zuständen Vertrauensannahmen (wir werden einige dieser Vertrauensannahmen im Detail besprechen). Das Hauptziel – und dies ist ein Thema, das in diesem Artikel immer wieder auftaucht – besteht darin, das Vertrauen in die Cross-Chain-Kommunikation auf ein Niveau zu minimieren, bei dem verschiedene Vertrauensannahmen kein großes Sicherheitsrisiko für auf Interoperabilität ausgerichtete Anwendungen darstellen. Dies ist ein wichtiges Ziel, denn wenn man ein Interoperabilitätsprotokoll erstellt, um verschiedene Blockchains zu verknüpfen, und eine auf der einen Seite der Trennlinie laufende Anwendung die falsche Behauptung akzeptiert, dass auf der anderen Seite ein beliebiges Ereignis stattgefunden hat, können schlimme Dinge – wirklich schlimme Dinge – passieren. So kam es beispielsweise zu Bridge-Exploits, weil ein Fehler es versierten Hackern ermöglichte ohne Sicherheiten auf der Quellkette zu hinterlegen. , (gefälschte) Beweise für nicht vorhandene Nachrichtenanforderungen und Mint-Tokens erfolgreich an eine Zielkette weiterzuleiten, Analyse bestehender Cross-Chain-Sicherheitsmechanismen Protokollentwickler haben seitdem Lösungen für das Problem der Validierung von Informationen bei der kettenübergreifenden Kommunikation gefunden. Die häufigste Lösung ist die Verwendung einer dritten Partei zur Überprüfung der Existenz/Gültigkeit einer kettenübergreifenden Transaktion. Die Logik ist einfach: Eine Anwendung auf Kette A kann möglicherweise den Status von Kette B nicht überprüfen, aber wir können sie überprüfen lassen, ob eine Gruppe von Personen (denen wir vertrauen oder von denen wir durch einen bestimmten Mechanismus erwarten, dass sie ehrlich sind) eine Information (oder Behauptung) validiert hat, die auf den Status von Kette B verweist. Dies wird als „externe Verifizierung“ bezeichnet, da eine andere Partei der Blockchain als Quelle der Wahrheit für On-Chain-Ereignisse fungiert und (normalerweise) einen oder mehrere Verifizierer einbezieht, die Signaturen auf Blockheadern aus der Quellkette ausführen. Sobald die Anwendung in der Zielkette diesen signierten Header erhält, kann sie verschiedene von einem Benutzer bereitgestellte Statusnachweise (Guthaben, Ereignisse, Einzahlungen/Abhebungen usw.) damit verifizieren. außerhalb Um ein gewisses Maß an Fehlertoleranz zu erreichen, verwenden einige Interoperabilitätsprotokolle ein Schwellenwert-Signaturschema, das eine Mindestanzahl privater Schlüssel erfordert, um eine Signatur für die Gültigkeit auszuführen (Multisignatur- und Multiparty-Wallets (MPC) sind gängige Beispiele). Aber eine Vielzahl ( von ) von Prüfern, die kettenübergreifende Zustände bestätigen, ist kein Allheilmittel für die Sicherheit, insbesondere bei kleinen Prüfergruppen. k n Beispielsweise könnte jemand gerade genug Unterzeichner in einem Multisig-Schema kompromittieren und dann betrügerische Abhebungen aus einer Cross-Chain-Bridge autorisieren. Ein MPC-Setup ist etwas sicherer (der Genehmigungsschwellenwert kann geändert und Keyshares häufiger rotiert werden), ist aber immer noch anfällig für Angriffe (insbesondere in Fällen, in denen eine Partei die Mehrheit der Keyshares kontrolliert). Abstecken Eine Möglichkeit, Vertrauensannahmen für Interoperabilitätsprotokolle zu reduzieren und die Sicherheit der Cross-Chain-Kommunikation zu erhöhen, besteht darin, dass externe Prüfer Sicherheiten als Sicherheit hinterlegen, bevor sie die Prüfaufgaben übernehmen. Das Staking schafft Sicherheit für extern geprüfte Systeme, insbesondere da gebundene Sicherheiten gekürzt werden können, wenn ein Prüfknoten eine Signatur für einen ungültigen Blockheader ausführt oder eine ungültige Cross-Chain-Transaktion genehmigt. Aber selbst dieser Ansatz bringt Probleme mit sich, je nachdem, ob das Staking genehmigungspflichtig oder genehmigungsfrei ist. Ein genehmigungspflichtiges System (bei dem Validierer auf eine Whitelist gesetzt werden müssen) ist oft auf wenige vorab genehmigte Einheiten beschränkt und lässt sich leichter entwickeln – es muss nicht in umfangreiche Anreizgestaltung investiert werden, insbesondere wenn die Validierer öffentlich bekannt sind und einen Anreiz haben, ehrlich zu handeln, um ihren Ruf zu wahren. Es ist auch effizient, da die Kommunikation – die für das Erreichen eines Konsenses notwendig ist – zwischen wenigen Parteien stattfindet, die sich bereits kennen. Natürlich öffnet ein System mit Berechtigung und identifizierbaren Teilnehmern die Tür für feindliche Angriffe. Ein Angreifer könnte sich beispielsweise erfolgreich als einer dieser Validierer ausgeben oder ihn bestechen und so die Mehrheitskontrolle erlangen. Schlimmer noch: Ein Proof of Authority (PoA)-System, bei dem die Validierer nicht wirklich eingesetzt werden (sondern einfach ernannt werden), reduziert die Kosten eines Angriffs auf das System auf Null (Angreifer können PoA-Validierer beispielsweise einfach durch Social-Engineering-Systeme kompromittieren und das System kapern). Ein Staking-System ohne Erlaubnis erhöht die Kosten für die Manipulation eines Systems, indem es jeder interessierten Partei (mit dem richtigen Kapital) erlaubt, mit der Validierung von kettenübergreifenden Operationen zu beginnen. In Kombination mit einem Konsensprotokoll, das eine Mehrheit von ≥ ⅔ erfordert, um Blockheader zu bestätigen, würden die Kosten für die Manipulation des Systems effektiv dem Mindestbetrag entsprechen, der erforderlich ist, um die Mehrheit der Prüfer im System zu korrumpieren. Außerdem haben Benutzer weniger Vertrauensannahmen (Prüfer können gekürzt werden), und ein dynamischer Satz von Prüfern erhöht die Schwierigkeit, bestimmte Knoten durch Techniken wie Social Engineering zu kompromittieren. Was könnte schon schiefgehen? Eigentlich eine Menge. Zunächst einmal muss der Einsatz zur Absicherung des Systems gleich oder höher sein als der Gesamtwert der Vermögenswerte, die im Falle eines Sicherheitsvorfalls (der die Sicherheit oder Funktionsfähigkeit des Interoperabilitätsprotokolls beeinträchtigt) gefährdet sind. Wenn das Gegenteil der Fall ist ( ), ist selbst die Androhung von Kürzungen zur Gewährleistung der Sicherheit wirkungslos, da der Gewinn aus der Beschädigung des Systems die Kosten der Beschädigung übersteigt. Gesamteinsatz zur Absicherung des Systems < Gesamtwert, der gefährdet ist Darüber hinaus würde der Versuch, die oben genannte Sicherheitseigenschaft umzusetzen, wahrscheinlich die Festlegung höherer Einsatzanforderungen für potenzielle Validierer erfordern. Dies wiederum führt zum Problem der Kapitalineffizienz – da die Sicherheit darauf beruht, dass die Validiererknoten zwei Dinge tun: Einzahlung einer großen Menge Geld im Voraus (als Einsatz), bevor an Validierungsaufgaben teilgenommen wird Das Geld über einen langen Zeitraum ungenutzt lassen (aus Sicherheitsgründen verhängen PoS-Protokolle lange Verzögerungen bei Abhebungen – einige davon können Wochen oder Monate dauern –, um Grenzfälle zu verhindern, in denen ein Prüfer einen Verstoß begeht, der zu einem Slashing führen kann, und versucht, sofort abzuheben, um den Verlust von Geldern durch Slashing zu vermeiden) Ein weiterer Punkt, den wir nicht erwähnt haben, ist die Belastung der Entwickler, die nun über kryptoökonomische Anreize nachdenken müssen, um unehrliches Verhalten zu verhindern, und komplexe Staking-Funktionen für das Token des Protokolls entwickeln müssen. Dies lenkt nicht nur von wichtigeren Aktivitäten ab – wie Produktentwicklung und Community-Engagement –, sondern erhöht auch die Komplexität und den kognitiven Aufwand des Entwicklungszyklus für Teams, die eine Interoperabilitätsinfrastruktur aufbauen. Optimistische Verifizierung „Optimistische Verifizierung“ ist eine andere Herangehensweise an das Problem der Cross-Chain-Sicherheit: Anstatt eine vertrauenswürdige Partei oder Gruppe zu bitten, den Cross-Chain-Zustand zu bestätigen, erlauben wir es . Entscheidend ist, dass die Partei, die einer Client-Interoperabilitätsanwendung (normalerweise „Relayer“ genannt) Ansprüche über Cross-Chain-Zustände macht, keinen Beweis dafür erbringen muss, dass der bestätigte Zustand gültig ist. Dies ergibt sich aus der „optimistischen“ Annahme, dass Relayer ehrlich handeln und nur gültige Ansprüche über Cross-Chain-Zustände stellen. jedem Aber natürlich rechnen wir damit, dass ein oder zwei (oder mehr) Relayer abtrünnig werden, weshalb optimistisch verifizierte Systeme von Relayern verlangen, eine kleine Kaution zu hinterlegen, bevor sie Statusnachweise einreichen. Die Ausführung von Transaktionen – solche, die sich auf von einem Relayer gemeldete Cross-Chain-Zustände beziehen – wird ebenfalls verzögert, um jedem, der das System beobachtet, genügend Zeit zu geben, ungültige Ansprüche innerhalb der anzufechten. Wenn sich der Anspruch eines Relayers als ungültig herausstellt, wird die hinterlegte Kaution gekürzt – wobei ein Teil davon an den Anfechter geht. Anfechtungsfrist Bei der optimistischen Verifizierung wird das Problem, einer Vielzahl ( ) oder Mehrheit ( ) von Verifizierern vertrauen zu müssen, zu dem Problem, einem Verifizierer ( ) zu vertrauen, dass er ehrlich handelt. Damit optimistisch verifizierte Protokolle sicher bleiben, genügt es, einen Akteur zu haben, der über genügend Statusdaten verfügt, um Transaktionen erneut auszuführen und zu erstellen, um betrügerische Transaktionen innerhalb der Verzögerungszeit anzufechten (daher die Sicherheitsannahme). k von n m von n 1 von n Betrugsnachweise 1 of n Dies reduziert den Aufwand, da das System mit einem einzigen Relayer ordnungsgemäß funktionieren kann (obwohl wir möglicherweise zwei oder mehr benötigen, um die Funktionsfähigkeit sicherzustellen). Es reduziert auch die für die Sicherheit erforderliche Einsatzmenge und fördert die Festlegung einer schnelleren Einsatzentbindungszeit (gebundene Sicherheiten können nach Ablauf der Verzögerungsfrist abgezogen werden). Darüber hinaus werden Interoperabilitätsprotokolle, die auf optimistischer Verifizierung basieren, als „Erben der Sicherheit der zugrunde liegenden Blockchain“ beschrieben; dies basiert auf der Idee, dass ein böswilliger Relayer nicht mit unehrlichem Verhalten davonkommen kann, wenn die zugrunde liegende Blockchain aktiv ist und keine Betrugsnachweise zensiert. Darüber hinaus würde ein Angriff auf das Protokoll einen Angriff auf die Blockchain selbst erfordern, da die Zensur von Transaktionen über einen längeren Zeitraum die Kontrolle über die Mehrheit der Knoten – und damit auch über die Beteiligungs-/Mining-Leistung – im Netzwerk erfordert. Aber selbst die optimistische Verifizierung hat einzigartige Nachteile. Wenn beispielsweise eine Verzögerung bei der Finalisierung und Ausführung von Überbrückungstransaktionen oder Nachrichtenanforderungen auftritt, erhöht sich die Latenz und das allgemeine Benutzererlebnis wird beeinträchtigt. Diese Art der kettenübergreifenden Sicherheit hat auch einige subtile „Fallstricke“ mit Auswirkungen auf die Sicherheit, wie etwa die Möglichkeit, dass eine böswillige Partei Transaktionen anficht, um ehrliche Relayer zu „betrüben“ und eine Art DDoS-Angriff auszuführen. gültige Da Betrugsnachweise von Natur aus (meistens) interaktiv sind, würde eine ungültige Anfechtung dazu führen, dass ehrliche Relayer Ressourcen verschwenden – einschließlich der für Gasgebühren für On-Chain-Transaktionen aufgewendeten Mittel. Infolgedessen verlieren ehrliche Relayer möglicherweise den Anreiz, Informationen kettenübergreifend weiterzuleiten, was möglicherweise Relayern die Möglichkeit gibt, Informationen kettenübergreifend weiterzuleiten. Die Anforderung, dass Challenger eine Mindesteinzahlung leisten müssen, könnte Griefing verhindern, aber eine hohe Mindesteinzahlung könnte Beobachter (die nicht über genügend Kapital verfügen) davon abhalten, ungültige Statusaktualisierungen anzufechten. unehrlichen ehrliche Einige Protokolle umgehen dieses Problem, indem sie die Herausforderungen auf eine berechtigte Gruppe von Beobachtern beschränken. Damit sind wir aber wieder beim ursprünglichen Problem, dass ein System nur mit einer kleinen Gruppe (vertrauenswürdiger) Teilnehmer abgesichert werden kann. Dieser Ansatz kann auch mehrere unbeabsichtigte Folgen haben, z. B. die Verringerung der Barriere für Absprachen zwischen Beobachterknoten und die Verbesserung der Chancen eines Angreifers, die Mehrheit der Knoten, die das System beobachten, zu manipulieren. Kryptografische Überprüfung Der letzte Ansatz zur Sicherung von kettenübergreifenden Interoperabilitätsprotokollen, den wir betrachten werden, stammt aus dem Bereich der kryptografischen Beweise. Die Idee ist einfach: Anstatt darauf zu vertrauen, dass Menschen kettenübergreifende Zustände verifizieren (was sich, wie die vorherigen Abschnitte gezeigt haben, in bestimmten Fällen als gefährlich erweisen kann), können wir stattdessen kryptografische Verifizierungsmechanismen verwenden und so Vertrauensannahmen auf ein Minimum reduzieren. Hier generieren ein oder mehrere Akteure für den (gültigen) Zustand einer Kette zur Verwendung in einer Interoperabilitätsanwendung. Diese Beweise sind : Wir können einen kryptografischen Beweis für einen kettenübergreifenden Zustand, wie ihn beispielsweise ein Blockheader ableitet, nehmen und seine Gültigkeit bestätigen. Sie sind außerdem : Ein von einer einzelnen Partei generierter Beweis kann von verschiedenen Parteien überprüft werden, ohne dass jemand kommunizieren muss (im Gegensatz zu interaktiven Betrugsbeweisen). Auf diese Weise entwickelte Interoperabilitätsprotokolle haben oft die niedrigsten Vertrauensannahmen, sofern das zugrunde liegende Beweissystem solide ist (d. h. ein Gegner kann keine gültigen Beweise für ungültige Behauptungen erstellen, außer mit einer vernachlässigbaren Wahrscheinlichkeit). SNARK-Beweise (Succinct Non-Interactive Argument of Knowledge) überprüfbar nicht interaktiv n Solche Protokolle unterscheiden sich auch von extern verifizierten Systemen, insbesondere wenn kryptografische Beweise bestätigen, dass jeder Block gemäß dem Konsensprotokoll einer Kette korrekt ist. Daher müsste ein Angreifer eine Supermehrheit des Validator-Sets der Quellkette kontrollieren – was erforderlich ist, um ungültige Blöcke abzuschließen –, um ein Interoperabilitätsprotokoll mithilfe kryptografischer Beweise des kettenübergreifenden Zustands zu manipulieren. Es ist auch leicht zu erkennen, wie dieser Ansatz einige der Nachteile beseitigt, die mit einigen zuvor besprochenen kettenübergreifenden Sicherheitsmechanismen verbunden sind: : Die Verwendung von zkSNARKs zur Überprüfung von Cross-Chain-Zuständen macht einen Staking-/Bonding-Mechanismus und die damit verbundene Ineffizienz einer Sperrfrist für Token überflüssig. Ebenso müssen Relayer keine Kaution hinterlegen (im Gegensatz zur optimistischen Überprüfung), bevor sie Ansprüche bezüglich Cross-Chain-Transaktionen geltend machen, da der beigefügte Nachweis den Anspruch bestätigt. Keine Kapitalineffizienz prägnant : Ohne die Notwendigkeit, eine Verzögerungszeit einzuführen, um zeitnahe Betrugsnachweise zu ermöglichen, kann ein Interoperabilitätsprotokoll eine kettenübergreifende Nachricht oder einen Überbrückungsvorgang ausführen, sobald ein SNARK-Nachweis, der diese absichert, verifiziert wurde. Allerdings ist die Generierung von Nachweisen in der Regel rechenintensiv, sodass ein extern verifiziertes System im Vergleich zu einem SNARK-basierten Interoperabilitätsprotokoll möglicherweise effizienter ist. Geringe Latenz Bei der Bewertung der Sicherheit einer „kryptografisch verifizierten“ Interoperabilitätslösung ist es wichtig, genau zu prüfen, welche Informationen über Cross-Chain-Zustände tatsächlich bewiesen und verifiziert werden. Zero-Knowledge-Beweise sind zu einem Schlagwort geworden, an dem sich viele Protokolle festhalten, um die tatsächlichen Vertrauensannahmen zu verschleiern, die ihren Protokollen zugrunde liegen. Da beispielsweise die Überprüfung aller Signaturen im Ethereum-Validator-Set ( ) in einem zkSNARK-Schaltkreis kostspielig sein kann, haben einige Protokolle in der Vergangenheit andere Mittel zur Ableitung von Beweisen für den Status von Ethereum übernommen. Ein Beispiel ist eine „ “-Brücke (wobei X jede beliebige Blockchain sein kann), die einen Beweis generiert, dass die Blockheader von einer Mehrheit des Sync Committee von Ethereum signiert wurden (das wir zuvor vorgestellt haben). aktuell über 925.000 Validatoren Ethereum to X Dies ist ein praktikablerer Ansatz (im Vergleich zur Überprüfung der öffentlichen Schlüssel von Tausenden von Validierern, die einen Block bestätigt haben). Aber wie bereits erläutert, werden Validierer im Sync Committee nicht dafür bestraft, dass sie falsche Blockheader signieren – wodurch eine nicht zu vernachlässigende Wahrscheinlichkeit besteht, dass eine Mehrheit der Sync Committee-Mitglieder sich absprechen oder bestochen werden kann, um Light Clients zu täuschen und die Sicherheit von Bridges/Messaging-Protokollen, die sich bei ihren Informationen auf das Sync Committee verlassen, effektiv zu gefährden. Darüber hinaus haben wir, wie im erläutert, erklärt, dass in einer idealen Welt, in der böswillige Sync Committees Kürzungen ausgesetzt wären, die wirtschaftliche Sicherheit auf den maximal möglichen Kürzungsbetrag begrenzt wäre. Hier sind einige Auszüge aus diesem Beitrag zum Kontext: Originalartikel zur Einführung der Lagrange State Committees Die Sicherheit von Light Client Bridges, ZK Bridges und Sync Committee Proofs basiert allesamt auf der Überprüfung von Signaturen des Ethereum Light Client Sync Committee. Da die Größe des Sync Committee festgelegt ist, ist auch die ihm zugrunde liegende wirtschaftliche Sicherheit auf ein 27-Stunden-Fenster begrenzt. Sobald das Slashing schließlich für Ethereum Sync Committees implementiert wird, wird die wirtschaftliche Sicherheit wie folgt begrenzt: Wirtschaftliche Sicherheit des Sync Committee = 512 Knoten * 32 Eth * 1650 USD/ETH = 27.033.600 USD Schwellenwert für Kompromisse im Sync-Komitee = 27.033.600 USD * 2/3 = 18.022.400 USD Während Light Client Bridges und ZK Light Client Bridges als Goldstandard für kettenübergreifende Interoperabilität gelten, ist die Menge an Vermögenswerten, die sie mit zufälligen Synchronisierungskomitees sichern können, stark begrenzt. Wie bereits gezeigt, ist die Menge an Sicherheiten, die kolludierende Knoten verbrennen müssten, um gleichzeitig alle Ethereum Light Client- und ZK Light Client Bridges zu kompromittieren, auf 18 Millionen US-Dollar begrenzt. Stellen Sie sich eine Situation vor, in der die Summe des Wertes aller durch alle Light-Client- und ZK-Light-Client-Brücken gesicherten Vermögenswerte einen Betrag von k beträgt. Wenn k 27 Mio. USD ist, wird es für eine Gruppe von böswilligen Akteuren im Synchronisierungsausschuss rentabel, bösartige Blöcke zu bestätigen, um die gesicherten Vermögenswerte zu kompromittieren. Wir empfehlen, den gesamten Artikel zu lesen, insbesondere den Abschnitt über die Einschränkungen der von Ethereum, um mehr Kontext zu den Problemen zu erhalten, die mit der Verwendung von randomisierten Synchronisierungskomitees zur Ableitung von Beweisen für kettenübergreifende Zustände verbunden sind. Wir empfehlen Ihnen auch, die Bemühungen von Polyhedra Network zu verfolgen . Light-Client-Bridges , den vollständigen Ethereum-PoS-Konsens in einem ZK-Schaltkreis zu beweisen Lagrange State Committees: Gemeinsame Sicherheit als Service für kettenübergreifende Kommunikationsprotokolle Da sich ein Großteil der Einleitung dieses Artikels mit gemeinsamer Sicherheit beschäftigt, ist es nur angemessen, dass wir eine gemeinsame Sicherheitslösung vorstellen, an der wir bei Lagrange Labs gearbeitet haben: . In diesem Abschnitt werden wir die Funktionsweise des Lagrange State Committee-Netzwerks untersuchen und seine Verbindung zum ZK Big Data-Stack von Lagrange sowie das Ziel verstehen, Tools zu entwickeln, die einen sicheren und Statuszugriff auf Ketten und zwischen Ketten ermöglichen. Lagrange State Committees ausdrucksstarken Was sind Lagrange-Staatskomitees? Das Lagrange State Committee (LSC)-Netzwerk ist ein einfaches und effizientes ZK-Light-Client-Protokoll für optimistische Rollups (ORUs), die sich auf Ethereum niederlassen (z. B. Optimism, Arbitrum, Base und Mantle). LSCs sind konzeptionell dem Sync Committee von Ethereum ähnlich und unterstützen leichte clientbasierte Anwendungen – wie Brücken und Interchain-Nachrichtenebenen –, die den Status eines optimistischen Rollups verwenden möchten, ohne übermäßige Vertrauensannahmen zu treffen. Ein Lagrange State Committee ist eine Gruppe von Client-Knoten, die über EigenLayer Sicherheiten im Wert von 32 ETH auf Ethereum neu eingesetzt haben. Mit anderen Worten ist ein Lagrange State Committee-Netzwerk ein AVS oder . Jedes Lagrange State Committee bestätigt die Endgültigkeit von Blöcken für ein bestimmtes optimistisches Rollup, sobald die zugehörigen Transaktionsstapel auf einer Datenverfügbarkeitsebene (DA) abgeschlossen sind. Diese Bestätigungen werden dann verwendet, um Statusnachweise zu generieren, die Anwendungen als Quelle der Wahrheit für den Status dieses bestimmten optimistischen Rollups verwenden können. Actively Validated Service Während das Sync Committee von Ethereum auf 512 Knoten begrenzt ist, unterstützt jedes Lagrange State Committee-Netzwerk eine unbegrenzte Anzahl von Knoten. Dies stellt sicher, dass die wirtschaftliche Sicherheit nicht künstlich begrenzt wird und die Anzahl der Knoten, die den Zustand eines optimistischen Rollups bestätigen, skaliert werden kann, wodurch die wirtschaftliche Sicherheit hinter Lagrange State Proofs dynamisch erhöht wird. Wie funktioniert das Netzwerk des Lagrange State Committee? Zwei Schlüsselkomponenten des Lagrange State Committee-Protokolls sind der Sequenzer und die Client-Knoten („Client-Knoten“ ist eine andere Bezeichnung für Validierer, die bei einem Lagrange State Committee registriert sind). Der Sequenzer ist eine zentrale Einheit, die für die Koordination von Attestierungen in einem Lagrange State Committee-Netzwerk und die Bereitstellung von Attestierungen für die Beweiser, die Zustandsnachweise erstellen, verantwortlich ist. Der Sequenzerknoten ist eigentlich eine Kombination aus drei Modulen mit unterschiedlichen Funktionen: , und . Sequencer Consensus Governance In bestimmten Abständen fordert das Sequencer-Modul von Client-Knoten Bestätigungen an, um Blöcke zusammenzufassen, die aus der Ausführung eines Stapels von Transaktionen resultieren, die in eine DA-Schicht geschrieben wurden. Anstatt diese Routine für jeden optimistischen Rollup-Block auszuführen, finden Sie unten eine kurze Analyse jedes Elements in der Blocknachricht: (1). : Ein Header eines finalisierten Optimistic Rollup (ORU)-Blocks. „Finalität“ bedeutet hier einen Block, der von Rollup-Knoten aus Transaktionsdaten abgeleitet wird, die auf einer bestimmten DA-Ebene finalisiert wurden. Beispielsweise wird die Finalität durch den für Optimism/OP-Stack-Rollups und einen L2-Block mit für Arbitrum- und Arbitrum-Orbit-Ketten definiert. (Erfahren Sie in mehr über die Rollup-Finalität.) Block_header sicheren L2-Header Ethereum-äquivalenter Finalität diesem Artikel (2). : Eine kryptografische Verpflichtung gegenüber dem Satz öffentlicher Schlüssel, die mit den Client-Knoten verknüpft sind, die einen Block signieren dürfen b. Von einem Client-Knoten wird erwartet, dass er einen Merkle-Baum erstellt, dessen Blätter die öffentlichen Schlüssel aller aktiven Komiteemitglieder darstellen, und die Wurzel des Merkle-Baums mit seinem Schlüssel BLS12–381 signiert. current_committee (3). : Eine kryptografische Verpflichtung für den Satz öffentlicher Schlüssel, die mit Knoten verknüpft sind, die den nächsten Block (b+1) signieren dürfen. Knoten, die ein State Committee verlassen möchten, müssen am Ende des Bestätigungszeitraums eine Transaktion an den Vertrag auf Ethereum senden, der die Registrierung und Abmeldung von Betreibern im State Committee AVS abwickelt. next_committee Lagrange Service Am Ende jeder Attestierungsperiode kann die Gruppe der Komiteeknoten geändert werden, wenn Betreiber vor Beginn der nächsten Attestierungsperiode einen Austritt oder Beitritt beantragen. Von den Clientknoten wird erwartet, dass sie einen des erstellen, indem sie die aktuelle Gruppe der für jedes Komitee registrierten Knoten aus dem Lagrange Service Contract abrufen. Merkle-Baum next_committee ELI5: Was sind Zustandsnachweise? Ein ist ein kryptografischer Nachweis des Zustands einer Blockchain: ein Nachweis eines Blockheaders aus einer Quellkette (Kette A), der verwendet werden kann, um der Zielkette die Existenz eines Zustands in der Quellkette zu beweisen, beispielsweise eine bestimmte Transaktion. Mit anderen Worten stellt ein Zustandsnachweis einen Nachweis des Zustands der Quellkette bei einer bestimmten Blockhöhe dar. Zustandsnachweis Zur Veranschaulichung anhand eines vorherigen Beispiels: Der Blockheader der Quellkette (Kette A), den Bobs Anwendung auf der Zielkette (Kette B) verwendet, um die Existenz der Alice-Überbrückungstransaktion zu überprüfen, ist ein Statusnachweis. Er stellt eine Zusammenfassung der Änderungen am Status der Quellkette zwischen dem vorherigen Block und dem aktuellen Block dar. Wenn Alices Merkle-Beweis anhand der im Blockheader der Kette A gespeicherten Transaktionsbaumwurzel überprüft wird, kann Bob die Überbrückungstransaktion auf Kette B (der Zielkette) getrost genehmigen, da der Statusnachweis die Ausführung von Alices Nachrichtenanforderung auf der Ursprungskette bestätigt. Das Lagrange State Committee-Netzwerk ist darauf ausgelegt, Zustandsnachweise für optimistische Rollups zu generieren, die durch Ethereum gesichert sind. Zustandsnachweise werden durch die Aggregation von BL12–381-Signaturen auf dem zuvor beschriebenen Tupel ( , und ) von mindestens zwei Dritteln der Knoten im State Committee generiert. Der Zustandsnachweis wird dann von einer SNARK-Schaltung basierend auf dem kollektiven Gewicht der Signaturen generiert, die einen bestimmten Blockheader bestätigen. block_header prev_committee next_committee Der Ansatz, von Attestierern zu verlangen, sich an die aktuellen und nächsten State Committees zu halten, ähnelt dem Ethereum Sync Committee-Protokoll und erreicht ein ähnliches Ziel: Light Clients können die Gültigkeit eines optimistischen Rollup-Blockheaders effizient und sicher überprüfen. Jeder State Proof ist kryptografisch durch eine Reihe von -Commitments verknüpft, die angeben, welche Knoten den nächsten Block signieren sollen. Daher reicht es aus, einen SNARK-Beweis zu überprüfen, der die folgenden rekursiven Eigenschaften im von den attestierenden Knoten signierten Blockobjekt beweist: next_committee Mindestens ⅔ der n Knoten im Staatskomitee haben den Blockheader b signiert. Der von Block b entspricht dem von Block b-1. current_committee next_committee Block b-1 ist entweder der Genesis-Block oder ist hinsichtlich dieser drei Bedingungen gültig. Interoperabilitätsprotokolle und andere Anwendungen, die einen sicheren optimistischen Rollup-Zustand mit schneller Endgültigkeit erfordern (z. B. Cross-Chain-Brücken und Messaging-Protokolle), können Zustandsnachweise von Lagrange State Committees mit minimalen Vertrauensannahmen verwenden. Wichtig ist, dass das Netzwerk des Lagrange State Committee die Sicherheit von Zustandsnachweisen gewährleisten kann, indem es böswilliger Attestierer und implementiert. deterministisches Slashing induktive Gültigkeitsnachweise Wie funktioniert das Netzwerk des Lagrange State Committee mit dem ZK Big Data Stack? Im ersten Beitrag der Serie über Lagranges Produktsuite haben wir die Beziehung zwischen verschiedenen Teilen des hervorgehoben: Lagrange State Committees, Recproofs, zkMapReduce und der Lagrange Coprocessor. Jede dieser Komponenten bietet in Kombination einen sicheren, effizienten Zugriff auf den Zustand und ausdrucksstarke, dynamische Berechnungen auf Zustandsdaten: ZK Big Data Stack #1. Das Lagrange State Committee-Netzwerk lässt sich für eine bessere Leistung mit den anderen Komponenten des ZK Big Data Stack integrieren Wir verwenden Recproofs und zkMapReduce, um aktualisierbare aggregierte öffentliche Schlüssel (APK)-Beweise für staatliche Ausschüsse zu erstellen. Dadurch können wir den kostspieligen und zeitaufwändigen Prozess der Deaggregation und erneuten Aggregation öffentlicher Schlüssel von Nichtunterzeichnern vermeiden, wenn eine neue aggregierte Signatur erstellt werden muss. Eine effiziente Aggregation der öffentlichen BLS-Schlüssel von Operatoren in den Lagrange State Committees (AVS) ermöglicht höhere Beteiligungsquoten im AVS, den Rechenaufwand für die Überprüfung von Bescheinigungen von State Committee-Knoten zu erhöhen. Aus diesem Grund können Lagrange State Committees eine potenziell unbegrenzte Anzahl von Knoten unterstützen und weisen eine superlineare Sicherheit auf, wenn mehr Kapital in die State Committees gesteckt wird. Weitere Informationen zu dieser Eigenschaft finden Sie in unserem Beitrag zur . ohne Skalierung von programmierbarem Vertrauen auf EigenLayer mit ZK Big Data Die Integration von Lagrange State Committees in den ZK Big Data-Stack bietet auch direktere Vorteile für Client-Anwendungen, die Lagrange State Proofs nutzen. Beispielsweise können wir die zkMapReduce-Funktion des Lagrange Coprocessor verwenden, um mehrere State Proofs aus n optimistischen Rollup-Ketten zu einem einzigen zu kombinieren. Dies ermöglicht eine „verschachtelte Verifizierung“, bei der eine einzige On-Chain-Transaktion gleichzeitig den Status mehrerer optimistischer Rollups verifiziert, und reduziert die Verifizierungskosten für Client-Dienste. Multi-Chain-State Proof #2: Der Lagrange-Coprozessor lässt sich in das Netzwerk des Lagrange State Committee integrieren, um vertrauenslose Off-Chain-Berechnungen zu ermöglichen Der Lagrange-Coprozessor – den wir in einem späteren Beitrag ausführlich analysieren werden – unterstützt kostengünstige und skalierbare Berechnungen von On-Chain-Daten, indem er Berechnungen außerhalb der Kette durchführt. Cross-Chain-Interoperabilitätsprotokolle, die in die Lagrange State Committees integriert sind, können auch in den Lagrange-Coprozessor integriert werden, um die Erweiterung ihrer Cross-Chain-Angebote um überprüfbare Berechnungen zu erleichtern. Beispielsweise möchte ein Entwickler, der eine Multi-Chain-Kreditanwendung erstellt, möglicherweise die Summe der von einem Benutzer in verschiedenen Rollups hinterlegten Sicherheiten berechnen. Unser freundlicher Entwickler kann den Lagrange-Coprozessor nutzen, um diesen Wert zu berechnen, und dabei die Blockheaderquelle verwenden, auf die das Cross-Chain-Protokoll bereits angewiesen ist. n Warum das Netzwerk der State Committees von Lagrange die Interoperabilität bei optimistischen Rollups revolutionieren wird Gemeinsame, superlineare Sicherheit für optimistische Rollup-Light-Clients Derzeit sind Interoperabilitätsprotokolle, die das Überbrücken zwischen optimistischen Rollup-Ketten unterstützen, unabhängig voneinander für die Überprüfung des Status von Quellketten verantwortlich. Die Sicherheit dieser Interoperabilitätsprotokolle hängt vom Mechanismus zur Überprüfung der Richtigkeit eines Blockheaders ab. Einige kettenübergreifende Kommunikationsprotokolle versuchen, Vertrauensannahmen zu reduzieren, indem sie natives Staking implementieren und eine Reihe von Prüfern auffordern, Sicherheiten zu hinterlegen, bevor sie Blockheader von Quellketten bestätigen. Dies fragmentiert jedoch die wirtschaftliche Sicherheit über verschiedene kettenübergreifende Protokolle hinweg, da die Kosten für die Beschädigung einer Teilmenge ( ) des Prüfersatzes jedes Protokolls geringer sind. k von n Im Gegensatz dazu ermöglichen Lagrange State Committees, dass mehrere Cross-Chain-Protokolle Sicherheit aus einem dynamischen Satz von Validierern ableiten, der unbegrenzt skalierbar ist. Dies ändert den Status quo – bei dem jedes Interoperabilitätsprotokoll unabhängig für die Überprüfung der Genauigkeit von Cross-Chain-Zuständen verantwortlich ist – zu einem Status, bei dem mehrere Anwendungen Cross-Chain-Zustände aus einer einzigen Quelle nutzen können. einzigen Im Gegensatz zu anderen Light-Client-Protokollen unterstützt das State Committee-Netzwerk von Lagrange eine dynamische, unbegrenzte Anzahl von Bestätigungsknoten. Das wirtschaftliche Gewicht der Signaturen, die jede Bestätigung sichern, kann daher dynamisch skaliert werden, wenn mehr Anteile in die State Committees fließen – was eine überlineare Erhöhung der Sicherheit ermöglicht und die Schwierigkeit erhöht, integrierte Cross-Chain-Protokolle isoliert anzugreifen. Dies macht das Lagrange State Committee effektiv zu einer „gemeinsamen Sicherheitszone“, in die jedes Cross-Chain-Protokoll (unabhängig von seiner Größe) für maximale Sicherheit eingebunden werden kann – ähnlich wie die Relay Chain auf Polkadot und Cosmos Hub auf Cosmos sekundäre Netzwerke im Multichain-Ökosystem sichern. Darüber hinaus ermöglicht die Integration mit der Restaking-Middleware von EigenLayer dem Netzwerk des Lagrange State Committee, die wirtschaftliche Sicherheit von Ethereum zu erweitern, um eine beliebige Anzahl nachgelagerter Cross-Chain-Kommunikationsprotokolle zu sichern. Reduzierter Aufwand für kettenübergreifende Produktentwicklungsteams Ein Entwickler, der heute ein kettenübergreifendes Interoperabilitätsprotokoll erstellt, muss eine Infrastruktur entwickeln, um unabhängig voneinander Watcher auszuführen, die den Status jedes unterstützten optimistischen Rollups überprüfen. Mit der wachsenden Anzahl integrierter optimistischer Rollups steigt der Infrastrukturaufwand für die Verwaltung der Sicherheit über jede Ursprungskette hinweg. Durch die Integration mit dem Lagrange State Committee kann der Entwickler seine Sicherheit auslagern und seine Ressourcen stattdessen auf die Optimierung seiner Produktfunktionen konzentrieren. Um das in den Kontext zu setzen: Jeder Lagrange-State-Beweis ist leichtgewichtig genug, um auf jeder EVM-kompatiblen Kette effizient verifiziert zu werden. Zusätzliche Sicherheit für bestehende Interoperabilitätsprotokolle Lagrange-Zustandsnachweise sind unabhängig von der Transportschicht, die zum Transport zu einer oder mehreren Zielketten verwendet wird. Dadurch können Interoperabilitätsanwendungen Lagrange-Zustandsnachweise nahtlos mit vorhandenen Sicherheitsmechanismen kombinieren. Beispielsweise kann ein Cross-Chain-Oracle oder ein Cross-Chain-Messaging-Protokoll mit einem unabhängigen Prüfersatz einen Lagrange-Zustandsnachweis als zusätzliche Sicherheitsmaßnahme prüfen, bevor Cross-Chain-Nachrichtenanforderungen von optimistischen Rollups weitergeleitet werden. Darüber hinaus kann ein vorhandenes Interoperabilitätsprotokoll – sobald es in das Netzwerk des Lagrange State Committee integriert ist – Unterstützung für optimistische Rollups hinzufügen, ohne dass die Validierer die Anzahl der von ihnen überwachten Ketten erhöhen müssen. Durch die Verwendung von Zustandsnachweisen aus dem Netzwerk des Lagrange State Committee müssen die Validierer nur Nachrichtenanforderungen zwischen Rollups weiterleiten. Ein Gateway-Vertrag in der Zielkette kann dann die Existenz der von den Relayern weitergeleiteten Nachrichten validieren, indem er einen Lagrange-Zustandsnachweis überprüft. Wie schneidet das Netzwerk des Lagrange State Committee im Vergleich zu anderen kettenübergreifenden Sicherheitsmechanismen ab? Lagrange State Committees schneiden im Vergleich zu bestehenden Interoperabilitätsinfrastrukturen, die Bonded Staking/Slashing, genehmigungsbasierte Validierung und optimistische Verifizierungsmechanismen (unter anderem) nutzen, um die Sicherheit von Cross-Chain-Statusnachweisen zu verbessern, gut ab. Nachfolgend einige Vergleiche: Externe Verifizierung durch erlaubnisfreie Validierer Lagranges Restaking-Modell mildert ein zentrales Problem bei Cross-Chain-Sicherheitsmechanismen, die reines PoS-Staking für die Sicherheit implementieren: . Nehmen wir zum Beispiel ein Cross-Chain-Protokoll, das von Validierern verlangt, den nativen Token eines Protokolls für den Bindungszeitraum zu kaufen und zu sperren. Da sich die Popularität des nativen Tokens des Cross-Chain-Protokolls ändert, wirkt sich die Volatilität des Vermögenswertpreises auf die gesamte wirtschaftliche Sicherheit des Netzwerks aus. Risikostapelung Die Preisvolatilität ist für das Lagrange State Committee-Netzwerk weniger problematisch, da die Sicherheit der Komiteeknoten auf über EigenLayer neu abgesteckten Sicherheiten basiert. Darüber hinaus haben neu abgesteckte Sicherheiten die Opportunitätskosten für potenzielle Validierer verringert, was eine stärkere Beteiligung an staatlichen Komitees und ein höheres Maß an wirtschaftlicher Sicherheit für Interoperabilitätsprotokolle bedeutet. Für Benutzer bedeutet dies niedrigere Gebühren und mehr Sicherheit im Vergleich zu Interoperabilitätsprotokollen, die ihre Sicherheit unabhängig voneinander aufbauen. Wir stellen auch fest, dass Konsensprotokolle, die in herkömmlichen Proof-of-Stake-Verfahren verwendet werden, Beschränkungen für die Anzahl der Validierer festlegen (z. B. begrenzt Tendermint BFT die Teilnahme auf 100-200 Validierer) und verhindern, dass herkömmliche PoS-Protokolle die wirtschaftliche Sicherheit so oft wie nötig skalieren. Im Gegensatz dazu verwendet das Netzwerk des Lagrange State Committee einen Attestierungsmechanismus, der eine potenziell unbegrenzte Anzahl von Knoten unterstützt, die am Konsens teilnehmen. Dadurch wird sichergestellt, dass das Netzwerk die Anzahl der Attestierer dynamisch erhöhen und dadurch robustere Garantien für die wirtschaftliche Sicherheit für Client-Anwendungen bieten kann. Externe Verifizierung durch autorisierte Validierer Auf Proof-of-Authority (PoA) basierende Cross-Chain-Protokolle verlassen sich auf Bescheinigungen, um Header von einer kleinen Gruppe autorisierter Knoten zu blockieren. Diese Ansätze haben sich in der Vergangenheit bei spektakulären Vorfällen als unsicher erwiesen, darunter der (5 von 7 Validierern kompromittiert) und (2 von 5 Validierern kompromittiert). Ronin-Hack der Harmony One Bridge-Hack Die Verwendung eines erlaubnisfreien validierten Systems wie dem Lagrange State Committee-Netzwerk verringert die Effizienz etwas im Vergleich zu einem zentralen Betreiber oder Validierer, der Signaturheader setzt. Angesichts des Risikos halten wir dies jedoch für einen vernünftigen Kompromiss. Erlaubnisfreie validierte Systeme verringern auch die Angriffsfläche für Unternehmen, die in den meisten Fällen die Mehrheit der Validierer in einem erlaubnispflichtigen System betreiben. Kanonische Überbrückung Das Lagrange State Committee-Netzwerk eliminiert die Latenz beim Senden von Cross-Chain-Nachrichten aus optimistischen Rollups. Jeder LSC fungiert als „Schnellmodus“ für Brücken und Nachrichtenprotokolle, deren Benutzer von einem optimistischen Rollup aus eine Brücke bauen möchten, ohne das Challenge-Fenster abzuwarten. Optimistische Rollups profitieren auch direkt von der Fast-Finality-Eigenschaft des LSC, da sie einen wichtigen UX-Problempunkt für L2-Benutzer löst. Diese Garantie ergibt sich aus der Beobachtung, dass (a) der Slashing-Mechanismus darauf ausgelegt ist, die Kosten für gegnerische Aktionen zu erhöhen, und (b) das Slashing von kollusiven Knoten in einem LSC im on-chain erfolgen kann, da es eine variable Zeitverzögerung beim Abheben des Einsatzes gibt. Zusammenfassend lässt sich sagen, dass Teilnehmer an einem LSC immer den Anreiz haben, korrekte Cross-Chain-Zustände zu bestätigen – wodurch Cross-Chain-Anwendungen Zustandsnachweise von einem LSC sofort und mit minimalen Vertrauensannahmen verwenden können, die durch die des Rollups unterstützt werden. langsamen Modus kanonische Brücke Abschluss Dieser Artikel hat eine ganze Reihe von Themen abgedeckt und wir hoffen, dass die Lektüre für Entwickler, Investoren, Enthusiasten und Benutzer im Bereich Interoperabilität lehrreich – wenn nicht sogar wertvoll – war. Im Laufe dieses Artikels haben wir die Definition gemeinsamer Sicherheit untersucht, was sie für die Entwicklung sicherer Protokolle bedeutet und wie die kettenübergreifende Interoperabilität von der Integration in eine gemeinsam genutzte Sicherheitsinfrastruktur profitieren kann. Wir haben auch Lagrange State Committees untersucht: unsere gemeinsame Security-as-a-Service-Lösung, die mit Blick auf kettenübergreifende Kommunikationsprotokolle entwickelt wurde. Lagrange State Committees ist Teil unserer Vision, sichere, vertrauensminimierte und effiziente Interoperabilität zu ermöglichen, und wird Teil eines größeren Stacks sein, der es Entwicklern ermöglicht, leistungsstarke kettenübergreifende Anwendungen für Benutzer zu erstellen. Die Multichain-Zukunft ist unausweichlich und es ist wichtig, dass Benutzer von der Nutzung einer Kette auf 10.000 Ketten umsteigen können, ohne einen signifikanten Sicherheitsverlust zu erleiden. Lösungen wie Lagrange State Committees (zusammen mit anderen Fortschritten bei der Cross-Chain-Sicherheit) sind für dieses Ziel von entscheidender Bedeutung. Da der Interoperabilität mehr Aufmerksamkeit denn je zuteilwird, ist eine Welt, in der die Bewegung zwischen Ketten sicher und effizient ist, für Krypto-Benutzer auf der ganzen Welt durchaus erreichbar. Danksagung ( ), ( ), ( ) und ( ) haben zu diesem Artikel beigetragen. Emmanuel wurde von Lagrange Labs beauftragt, beim Verfassen dieses Artikels zu helfen. Emmanuel Awosika 2077 Research Omar Yehia Lagrange Labs Ismael Hishon-Rezaizadeh Lagrange Labs Amir Rezaizadeh Lagrange Labs Eine Version dieses Artikels wurde zuvor veröffentlicht. hier