Secure AltDA Integration for Ethereum L2s: An End-to-End Validation Framework
Dieses Paper präsentiert ein kanonisches Validierungsframework für die sichere Integration von Alternative Data Availability (AltDA) in Ethereum L2s, welches ein deterministisches Translationsmodell definiert, um Konsensfehler und Bridge-Angriffe zu verhindern, indem sichergestellt wird, dass jeder adversarielle Input ein einzigartiges, wohldefiniertes Ergebnis über diverse Architekturen wie Celestia-Blobstream und EigenDA hinweg liefert.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich Ethereum als eine riesige, geschäftige Stadt vor, in der alle die gleichen Verkehrsregeln befolgen. Um diese Stadt schneller zu machen, haben Menschen „Layer-2“-Nachbarschaften (L2) gebaut. Diese Nachbarschaften regeln ihren eigenen Verkehr (Transaktionen), verlassen sich aber auf die Hauptstadt (Ethereum), um Streitigkeiten beizulegen und das offizielle Protokoll zu führen.
Normalerweise posten diese Nachbarschaften ihre Verkehrsprotokolle direkt auf das schwarze Brett der Hauptstadt. Aber das schwarze Brett hat ein Größenlimit. Wenn zu viele Nachbarschaften gleichzeitig etwas posten wollen, verstopft es und der Verkehr verlangsamt sich.
Die Lösung: Der „AltDA“-Kurierdienst
Um dieses Problem zu lösen, begannen einige Nachbarschaften, Alternative Data Availability (AltDA)-Systeme zu nutzen. Anstatt das gesamte Protokoll in der Hauptstadt zu posten, posten sie einen winzigen „Beleg“ (eine Verpflichtung/Commitment) in der Stadt und speichern das eigentliche, schwere Protokoll bei einem spezialisierten Hochgeschwindigkeits-Kurierdienst (wie Celestia, EigenDA oder Avail).
Das Problem: Die „Beleg-Falle“
Das Papier argumentiert, dass es nicht ausreicht, einfach nur einen Beleg zu haben. Es ist so, als würde ein Restaurant Ihnen einen Beleg für eine Mahlzeit ausstellen, die Sie gar nicht bestellt haben, oder einen Beleg, auf dem „Pizza“ steht, während die Küche in Wirklichkeit „Giftiges Zeug“ serviert hat.
Wenn die Nachbarschaft keine strikte End-zu-Ende-Regelwerk zur Überprüfung dieser Belege hat, können böswillige Akteure das System austricksen. Sie könnten:
- Einen gültigen Beleg für ein Protokoll posten, das nicht mehr existiert (der Kurier hat es weggeworfen).
- Einen Beleg posten, der zum Protokoll passt, aber das Protokoll Anweisungen enthält, die gegen die Regeln der Nachbarschaft verstoßen.
- Einen Beleg posten, der gültig aussieht, aber je nach Leser zu zwei verschiedenen Ergebnissen führt.
Wenn das Abwicklungssystem der Nachbarschaft (der Richter) diese schlechten Belege akzeptiert, ohne die gesamte Kette der Zuständigkeit zu prüfen, könnte die Nachbarschaft einfrieren oder Menschen könnten über die Brücke, die die Nachbarschaften verbindet, Geld stehlen.
Die Lösung des Papers: Das „Total Validation“-Framework
Die Autoren schlagen ein striktes, schrittweises Checklist-Verfahren (ein „Canonical Validation Framework“) vor, das jede Nachbarschaft befolgen muss, um Sicherheit zu gewährleisten. Sie vergleichen diesen Prozess mit einem vierstufigen Sicherheitstunnel:
- Der Posteingang (Der Briefkasten): Die Hauptstadt wirft ein Stück Papier (Bytes) in den Briefkasten der Nachbarschaft. Es kann alles sein – ein gültiger Beleg, eine Kritzeleien oder eine leere Seite.
- Die Belegprüfung (Das Siegel des Kuriers): Die Nachbarschaft prüft, ob das Papier ein gültiger Beleg vom Kurierdienst ist. Ist die Signatur echt? Ist der Beleg aktuell (nicht abgelaufen)?
- Der Paketabgleich (Die Bindung): Die Nachbarschaft geht zum Kurier, um das eigentliche Protokoll (den Blob) zu holen. Sie müssen beweisen, dass das Protokoll, das sie abgeholt haben, exakt mit dem Beleg übereinstimmt, den sie besitzen. Ein Austausch ist nicht erlaubt.
- Die Übersetzung (Die Nutzlast): Schließlich müssen sie das Protokoll in eine klare Anweisung für die Nachbarschaft übersetzen. Wenn das Protokoll Kauderwelsch ist oder wenn zwei verschiedene Personen es unterschiedlich interpretieren würden, muss das System es sofort ablehnen.
Die goldene Regel: „Alles muss eine Antwort haben“
Die wichtigste Idee des Papers ist die Total Validation (Gesamtwertprüfung).
- Wenn der Input gut ist, sagt das System: „Hier ist eine gültige Anweisung.“
- Wenn der Input schlecht ist (falscher Beleg, abgelaufen, falsches Paket), muss das System sagen: „Ablehnen.“
- Wenn der Input vorübergehend nicht verfügbar ist (der Kurier macht gerade Pause), muss das System sagen: „Warten, aber nicht abstürzen.“
Das System darf nicht sagen: „Ich weiß nicht, was ich damit machen soll“, und dann einfrieren oder in Panik geraten. Es muss immer eine klare, deterministische Antwort geben.
Was sie herausgefunden haben
Die Autoren haben reale Beispiele untersucht (wie Systeme, die Celestia, EigenDA oder Avail nutzen) und diese Checkliste angewendet. Sie fanden heraus, dass:
- Einige Systeme sehr gut darin waren, den Beleg zu prüfen (der DA Verifier).
- Aber viele Schritte in der Mitte fehlten, wie etwa die Prüfung, ob der Beleg zu alt war (Aktualität/Recency) oder ob das Protokoll perfekt zum Beleg passte (Bindung/Binding).
- Sie zeigten, dass, wenn man auch nur einen dieser Schritte überspringt, böswillige Akteure „unterbestimmte“ (under-constrained) Situationen schaffen können, in denen sie eine Statusänderung beanspruchen können, die das System akzeptiert, obwohl die Daten dies eigentlich nicht stützen. Dies könnte dazu führen, dass Brücken gehackt werden oder das gesamte Netzwerk einfriert.
Das Fazit
Sicherheit bedeutet nicht nur, dass der Kurierdienst ehrlich ist. Es geht um den gesamten Prozess innerhalb der Nachbarschaft. Man kann den besten Kurier der Welt haben, aber wenn die internen Regeln der Nachbarschaft für die Überprüfung von Belegen schlampig sind, ist das gesamte System unsicher. Das Paper liefert den Bauplan für diese internen Regeln, damit jeder einzelne Datensatz korrekt geprüft, verifiziert und übersetzt wird, bevor er Teil der offiziellen Historie wird.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.