🧵 @Agglayer v0.3 ist da. Die meisten Bridges verlassen sich immer noch auf "Vertrau uns einfach"-Vibes. Diese Version dreht das Modell endlich um: "Trauen Sie der Brücke nicht, überprüfen Sie den Zustand." Lassen Sie mich Ihnen erklären, was sich geändert hat und warum es wichtig ist 👇

Vor v0.3 konzentrierte sich Agglayer hauptsächlich auf die Verifizierung von Cross-Chain-Nachrichten – nicht auf das, was innerhalb der Ketten passierte. Angenommen, Kette A sendet 100 USDC an Kette B. Das alte Modell hat nur überprüft, dass "eine Nachricht zum Senden von 100 USDC" übergeben wurde. Aber es bewies nicht: - ob Chain A tatsächlich 100 USDC von Ihrer Wallet abgezogen hat - oder ob Chain B die Token korrekt geprägt hat Sie vertrauten darauf, dass die Sequenzer oder die Brückenlogik "das Richtige tun". Mit v0.3 fügt Agglayer eine vollständige Überprüfung dieser internen Schritte hinzu. Es wird überprüft: - Dass der Zustandsübergang auf Kette A gültig war (z. B. Saldo abgezogen wurde) - Dass das Verhalten der Brücke und der Anspruch auf Kette B mit dem übereinstimmen, was tatsächlich passiert ist Kein blindes Vertrauen mehr. Jetzt ist alles beweisbar.

Agglayer v0.3 ist ein großes Upgrade des pessimistischen Beweises. Die Kernidee? Chains fügen jetzt einen Beweis hinzu, der zeigt, dass sie ihren eigenen Block ordnungsgemäß abgeschlossen haben – basierend auf ihren eigenen Regeln. Stellen Sie es sich wie #2FA für die Abrechnung vor: Ein Faktor ist der Zustandsunterschied, der zweite ist der Nachweis, dass der Block ehrlich gebaut wurde.

Die Sicherheit von Agglayer v0.3 wird durch einen dreistufigen Ablauf erhöht: 1️⃣ Der Zustandsübergangsnachweis weist seinen eigenen Zustandsübergang nach (über zk proof oder ECDSA) 2️⃣ Der AggProver-Beweis überprüft den Zustandsübergangsnachweis und überbrückt Einschränkungen (d. h. Exits, Root-Änderungen) 3️⃣ Zum Schluss wird das Ganze erneut ausgeführt. Dadurch ist das gesamte System überprüfbar und manipulationssicher – keine Abkürzungen, keine Vertrauensannahmen. Jeder Schritt wird in einer zkVM ausgeführt, wobei wir @SuccinctLabs SP1 verwenden! Das sind drei SP1 Proofs pro Kette State Commitment! Dreifaches Vertrauen! Es ist vertrauenswürdig, modular und viel sicherer. Lassen Sie uns jede Schicht nacheinander erklären:

Schritt 1 – Beweis für den Zustandsübergang Hier beweist jede Kette, dass ihr eigener interner Zustandsübergang gültig ist. Wenn Sie ein zk-Rollup haben, generieren Sie einen vollständigen Gültigkeitsnachweis (z. B. Plonky2/3, STARK usw.). Wenn dies nicht der Fall ist, können Sie den neuen Zustandsstamm mit ECDSA signieren. Das Ziel hier: zu beweisen "Ich habe diese Transaktionen verarbeitet und meinen Zustand ehrlich aktualisiert". Die Ausgabe ist ein Beweis für den lokalen Zustand – sie sagt noch nichts über Brücken aus, nur interne Korrektheit.