Originaltext: „L2Bridge Risk Framework“

Autor: bartek.eth

Vaibhav Chellani von Socket und ich wollten eine Risikoarchitektur zur Bewertung der Sicherheitsprofile verschiedener Brückenarchitekturen vorschlagen.

Wie bei verschiedenen L2-Risiko-Frameworks besteht unser übergeordnetes Ziel darin, eine Lösung schnell in eine bestimmte Lösungskategorie mit ähnlichen Merkmalen „kategorisieren“ zu können und gleichzeitig den Benutzern ausreichend detailliert darzustellen, wie sie diese Brücken verwenden werden . Welche Sicherheitsannahmen müssen akzeptiert werden?

Wir konzentrieren uns hauptsächlich auf Brücken zwischen Ethereum und anderen Ketten, da wir diese bald auf l2beat.com behandeln werden (Anmerkung des Übersetzers: Die Brückenspalte ist jetzt online), aber die grundlegenden Überlegungen zur Sicherheit dieser Lösungen gelten auch für die Überbrückung jeder beliebigen Kette zu einer anderen Kette. Derzeit sind wir auf der Suche nach Feedback von der breiteren Community zu diesem vorgeschlagenen Rahmenwerk.

Brückentyp

Für Endbenutzer bedeutet Asset Bridging den Empfang einer Anzahlung eines bestimmten Assets von der Quellkette und das Senden dieses Assets an den Benutzer in der Zielkette.

Ein typischer Überbrückungsprozess besteht beispielsweise darin, dass Alice Gelder an den Überbrückungsvertrag von Kette A überweist und Alice dann Gelder von der Brücke auf Kette B erhält.

Im Großen und Ganzen läuft dieser Prozess auf zwei Arten ab:

Nachrichtenbasierte Token-Brücken – Diese Brücken ermöglichen den Liquiditätsfluss über Ketten in Form von Nachrichten. Im Allgemeinen ermöglichen sie das Mining eines Vermögenswerts in der Zielkette, nachdem er in der Quellkette gesperrt oder zerstört wurde. Beispiele: Rollup Bridge, Polygon Native Bridge, Anyswap (anyCall) und Axelar-Netzwerk. Liquiditätsnetzwerk – Es gibt auch Brücken, die einige der geprägten Vermögenswerte einlösen. Sie ermöglichen Benutzern die Übertragung von Vermögenswerten auf andere Ketten, vorausgesetzt, diese Vermögenswerte wurden zuvor über die „Message Bridge“ übertragen. Beispiele: Connecxt basierend auf Nomad Bridge, Hop basierend auf Hop Optimistic Bridge, einige andere HTLC (Hash Time-Lock Contract, Hash Time Lock Contract) und bedingte Übertragungen (wie Nova usw.).

Sicherheit von Message-Passing-Brücken

In diesem Abschnitt werden wir versuchen, diese verschiedenen Methoden zur Validierung kettenübergreifender Nachrichten zu erklären, die von mehreren Überbrückungsprotokollen verwendet werden. Wie in der Abbildung oben dargestellt, nutzt Token-Bridging die Sicherheit von Message-Passing-Bridging.

Der Light-Client überprüft die Gültigkeit des Status

Beschreibung: Eine Brücke, die die Gültigkeit des Zustandsübergangs der Quellkette auf die Zielkette überprüft. Dieser Verifizierungsprozess wird durch einen Zero-Knowledge-Proof (der Zustandsübergangsprozess wird von der Generierung eines ZK-Beweises begleitet) oder ein Fraud-Proof-System (das es unabhängigen Verifizierern ermöglicht, die Gültigkeit der neuen State Root anzufechten) implementiert.

Beispiel: Alle Rollups sind hier Beispiele. L1 überprüft den Statusübergang von L2 durch FraudProof (Betrugsnachweis) oder ValidityProof (Gültigkeitsnachweis).

Leichter Konsens zur Kundenüberprüfung

Beschreibung: Eine Brücke, die den Konsens der Quellkette in der Zielkette überprüft. Dies hängt vom von der Quellkette verwendeten Konsensmechanismus ab und umfasst normalerweise eine Überprüfung der Quorumssignatur des aktuellen Validierungsausschusses, wenn die Quellkette ein Vorschlags- und Abstimmungs-Konsensprotokoll im PBFT-Stil verwendet (z. B. Tendermint, HotStuff, Casper FFG-Protokoll). Wenn die Quellkette alternativ ein PoW-Protokoll oder ein PoS-Protokoll im Stil der „längsten Kette“ (wie Ouroboros, ETH 2.0 LMD Ghost usw.) verwendet, verwenden Sie die entsprechenden Forking-Regeln, um die längste Kette zu überprüfen.

Beispiele: NEAR Rainbow Bridging (ignoriert die optimistische Komponente im Zusammenhang mit der Komplexität des Verifizierungsprozesses des NEAR-Signaturmechanismus), Polygons PoS-Bridging (Überprüfung des Konsenses der Heimdall-Kette) und Cosmos IBC (Überprüfung der Signatur einer anderen Cosmos-Kette) .

externer Prüfersatz

Beschreibung: Verwenden Sie externe Validatoren als Brücke zur Quelle der Wahrheit, d. h. Validatoren, die ein unabhängiges Komitee bilden, und nicht Validatoren in der Quell- und Zielkette. Abhängig von der von diesen Validatoren verwendeten Implementierung können sie MultiSig (Mehrfachsignatur) verwenden, einen Konsensalgorithmus ausführen (normalerweise einen aus der Vorschlags- und Abstimmungsklasse), einen Schwellenwertsignaturmechanismus (TSS, Schwellenwertsignaturmechanismus) oder SGX usw. verwenden ... fallen unabhängig von der verwendeten Technologie unter diese Verifizierungsmethode.

Beispiele: Wormmhole, Multichain, Axelar, DeBridge, Synapse, Stargate.

optimistische Bestätigung

Beschreibung: Eine Bridge mit einer Challenge-Periode (Challenge-Periode, Anmerkung des Übersetzers: bezieht sich auf die Zeitspanne, in der andere Validatoren die Gültigkeit der Bridge-Nachricht anfechten können, wenn sie sie für ungültig halten).

Die ehrliche Partei bei dieser Art der Überprüfung vermeidet in diesem Zeitraum die Einbeziehung betrügerischer Informationen. Es sind jedoch mehrere wichtige Parameter zu berücksichtigen:

Dauer des Herausforderungszeitraums: Je länger, desto besser. Größe des Beobachtersatzes: Keine Erlaubnis erforderlich > Erlaubnis erforderlich

Beispiele: Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.

Hybride Authentifizierungsmethode

Beschreibung: Es gibt eine Struktur, die die oben genannten Verifizierungsmethoden mischt.

Sicherheit des Liquiditätsnetzwerks

Zusätzlich zum eigentlichen Versenden von Vermögenswerten über Ketten hinweg gibt es noch eine weitere Methode: Der kettenübergreifende Austausch (Swap) kann nur durch einen Besitzerwechsel durchgeführt werden, ohne dass Vermögenswerte über Ketten hinweg verschoben werden. (Anmerkung des Übersetzers: Wenn die Vermögenswerte einer Partei den Besitzer wechseln, gehen sie in den Besitz einer anderen Partei über, d. h. der Eigentümer der Vermögenswerte wechselt.)

Nehmen Sie ein einfaches Beispiel: Alice in Kette A möchte Vermögenswerte auf Kette B übertragen. Bob (Liquiditätsanbieter, LP) verfügt bereits über Vermögenswerte mit dem gleichen Wert auf Kette B. Er nutzt seine Vermögenswerte auf Kette B, um Umtauschdienste für Alices Guthaben auf Kette A bereitzustellen und erhebt Servicegebühren. Am Ende erhält Alice den Vermögenswert auf Kette B und Bob erhält den Vermögenswert + Servicegebühr auf Kette A.

Dieser Teil beschreibt nur die Sicherheit des „Exchange“-Protokolls, d. h. wie wahrscheinlich es ist, dass der LP mit dem Geld davonkommt, nachdem er Ihre Einzahlung in der Quellkette akzeptiert hat. Diese Börsenwerte verfügen über die Sicherheit der Message-Passing-Brücke, die sie fälscht.

Es gibt auch einige andere Möglichkeiten, Vermögenswerte auszutauschen:

HTLC: Wird auch als Hash-Time-Lock-Vertrag bezeichnet und kann für den atomaren Austausch von Vermögenswerten zwischen zwei Parteien entlang der Kette verwendet werden. Normalerweise sind vom Benutzer nur zwei Schritte erforderlich, einer zum Sperren und der andere zum Entsperren. Ein mögliches Fehlerszenario besteht darin, dass Ihre Gelder für eine festgelegte „Ruhe“-Zeitspanne gesperrt sind. Beispiele: Connext NXTP, Liqualit. Bedingte Übertragung: Ermöglicht LPs die Verwendung von Shortcut-Messaging-Brücken, sodass LPs den Endbenutzern sofort Gelder bereitstellen und Gelder von der Messaging-Brücke erhalten können, wenn Gelder überbrückt werden. Im Falle eines Scheiterns, wenn keine LPs zur Bereitstellung von Liquidität vorhanden sind, wird der langsame Pfad aktiviert. Beispiele: Hop, Connext Amarok, MakerDAO Teleport. Externer Validator: Ermöglicht Benutzern die Überweisung von Geldern an einen vertrauenswürdigen Bridge-Anbieter, der verspricht, die Gelder an eine andere Kette weiterzugeben. Ein mögliches Fehlerszenario besteht hier darin, dass Ihr Geld verloren geht. Beispiel: Binance

Zensurwiderstand

Wir werden uns die Sicherheitsannahmen im Zusammenhang mit der Wahrscheinlichkeit ansehen, dass eine einzelne von einer Bridge gesendete Nachricht zensiert wird. Praktischer betrachtet werden wir auch untersuchen, ob eine einzelne Nachricht (Token-Übertragung) von der Brücke zensiert oder ignoriert wird, und wenn ja, welche Konsequenzen dies für die Gelder des Benutzers haben wird (werden die Gelder an den Benutzer zurückgegeben oder werden sie zurückgegeben). „hängen bleiben“ (Status „Übertragung läuft“).

Typische Lösung:

Nutzen Sie die Zensurresistenz der zugrunde liegenden Kette (z. B. ein Rollup). Verlassen Sie sich auf die Ehrlichkeit des Validatorsatzes

Insgesamt aktiver Fehler

Im Hinblick auf allgemeine Liveness-Ausfälle betrachten wir die Folgen des „Ausschaltens“ einer Brücke. Bei einer Bridge, die einen externen Satz von Validatoren verwendet, könnten wir beispielsweise die Sicherheit der Benutzergelder für den Fall prüfen, dass diese Validatoren über einen längeren Zeitraum (vielleicht auf unbestimmte Zeit) offline sind. Zu den häufigsten Situationen, die auftreten können, gehören:

Aktivieren Sie den langsamen Pfad: Der Standardmodus ist der langsame Pfad und Sie verlieren kein Geld. Benutzer können am Netzwerk teilnehmen, ein Validator werden und feststeckende Übertragungstransaktionen selbst abwickeln Brückenbetreiber geht online.

Liquidität

In diesem Abschnitt werden wir versuchen, die auf dem Brückenvermögenswert verfügbare Liquidität zu analysieren. Kann die Bridge Vermögenswerte prägen, erfordert sie LP, können Benutzer immer eine beliebige Menge an Token abheben oder übertragen, oder sind sie auf externe LPs angewiesen und der Bridge gehen möglicherweise „die Mittel aus“.

Unbeschränkt (die Brücke kann native/autoritative Token prägen) Erlaubt (Liquidität wird vom Brückenbetreiber bereitgestellt) Erlaubnislos (jeder LP kann Liquidität bereitstellen)

Zusätzliche Gedanken und Metriken, Aktualisierbarkeit, zugelassene Akteure, Übertragungsvolumen in den letzten 24 Stunden, einzigartige Übertragungen in den letzten 24 Stunden, verfügbare Liquidität, unterstützte Token/Blockchains