Den Nachmittag damit verbracht, in Dunks Brücken-Informationshinweisen zu graben, statt irgendetwas Produktives mit meinem Samstag zu machen. Am 16. August begann eine teamverwaltete Wallet, die mit Bridge-Operationen verbunden ist, sich seltsam zu verhalten, und innerhalb weniger Stunden wurden die Adressen deaktiviert und recycelt. Was mich aufhielt, war eine einzige Zeile: Das war kein Problem auf Protokollebene in DuskDS. Technisch stimmt das. $DUSK mainnet produzierte weiterhin Blöcke, als wäre nichts passiert.

Aber genau das hatte ich vorher nicht bedacht. Eine datenschutzfreundliche, MiCA-konforme Settlement-Layer kann architektonisch völlig stimmig sein und trotzdem ihre am stärksten exponierte Angriffsfläche eine Wallet sein, die ein Teammitglied nebenbei verwaltet. #dusk ist hier nicht ungewöhnlich; die meisten Bridges funktionieren so, aber dass es so klar ausformuliert war, machte den Unterschied zwischen „Kettensicherheit“ und „Brückensicherheit“ weniger akademisch.

Ich bin mit der Annahme reingegangen, ein gehärtetes L1 bedeute auch ein gehärtetes Perimeter. Tut es nicht, nicht automatisch. @Dusk bridge ist bis zum Zeitpunkt des Verfassens dieser Zeilen immer noch pausiert, was mir sagt, dass sie das auch wissen.

Trotzdem nicht sicher, wie man das Problem mit der Human-Wallet behebt, ohne einfach… keine zu haben.