Am 16. Januar 2025 schließt SSP Wallet v1.9.0 ein mehrwöchiges Sicherheits-Review mit Halborn der Solidity-Verträge von SSPs Account Abstraction ab — der Factory und der Account Implementation hinter jeder Ethereum- und Sepolia-Adresse. Das Audit fiel an den entscheidenden Stellen sauber aus, mit nur drei Informationsbefunden und zwei Befunden niedriger Priorität, alle in ungenutztem oder totem Code. Trotzdem haben wir uns entschieden, jeden einzelnen davon zu beheben, die Verträge neu zu deployen und die saubereren Versionen in v1.9.0 auszuliefern. Dieses Re-Deployment ist eine Breaking Change für Ethereum- und Sepolia-Nutzer: Eure deterministische Adresse auf diesen beiden Chains ändert sich nach dem Update.
TL;DR
- Halborn hat den Solidity-Teil von SSPs Account Abstraction auditiert: die Verträge Factory und Account Implementation.
- Befunde: 3 informativ, 2 niedrig, 0 mittel, 0 hoch. Alle in ungenutzten oder toten Codepfaden. Die zuvor deployten Verträge waren und bleiben sicher.
- Wir haben dennoch neu deployt, um die Codebasis vollständig sauber zu halten — neue Factory- und Account-Implementation-Verträge erscheinen in v1.9.0.
- Breaking Change: Ethereum- und Sepolia-Adressen ändern sich nach dem Update. Bewegt die Gelder vor dem Update oder kontaktiert den SSP-Support für eine Migrationsanleitung.
- UTXO-Chains — Bitcoin, Zcash, Bitcoin Cash, Flux — sind nicht betroffen.
Was Halborn auditiert hat
Der Umfang war der Solidity-Teil der ERC-4337-Verträge mit Schnorr-Multisig, die wir in v1.6.0 ausgeliefert und seitdem weiterentwickelt haben. Konkret: das Repository @runonflux/account-abstraction — der Factory-Vertrag, der einen Account deterministisch deployt, sobald ein Nutzer zum ersten Mal transagiert, und der Account-Implementation-Vertrag, der definiert, wie dieser Account UserOperations validiert, Schnorr-Signaturen prüft und dem ERC-4337-Fluss aus Bundler und EntryPoint folgt.
Halborns Technikteam hat die volle Bandbreite an Tests durchgeführt, die sie für produktive Smart Contracts vorsehen. Das Repository ist, in ihren Worten, robust, respektiert die ERC-4337-Empfehlungen und implementiert Schnorr sauber. Diese Schlussfolgerung zählt, weil die Schnorr-Implementierung der Teil des Designs ist mit dem kleinsten Vorlauf bestehender Arbeit — jedes andere Stück des AA-Stacks wurde in der Branche vielfach auditiert, aber aggregierte Schnorr-Signaturen innerhalb eines ERC-4337-Validators sind etwas, das wir selbst gebaut haben.
Was gefunden wurde
Der Bericht enthält 3 informative und 2 niedrige Befunde — keine mittleren, keine hohen, keine kritischen. Ihr könnt den vollständigen Bericht unter halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig lesen.
Jeder Befund liegt in Code, der entweder in den Live-Verträgen ungenutzt war oder Teil eines Pfads, der nicht gegen reale Nutzergelder ausgeführt wurde — defensives Gerüst, Restzweige aus einer früheren Iteration, in diese Richtung. Keiner beschreibt einen Weg, auf dem ein Angreifer Gelder entwenden, eine Signatur fälschen oder einen Account brechen könnte. Die auf Ethereum Mainnet deployten Verträge waren während des Audit-Fensters und danach durchgehend vollständig sicher.
Warum wir trotzdem neu deployt haben
Zwei Gründe. Erstens: Eine saubere Codebasis ist selbst eine Form von Sicherheit. Toter Code, der in einen deployten Vertrag kompiliert, ist toter Code, mit dem zukünftige Auditor:innen, Integrator:innen und Beitragende argumentieren müssen. Ihn herauszunehmen reduziert die Fläche, die jede künftige Prüfung anschauen muss — weniger Zweige, weniger Annahmen, weniger Möglichkeiten, den Vertrag misszuverstehen.
Zweitens: Wenn man die Chance hat, die Version auszuliefern, die jeden Befund adressiert, statt der Version, die sie aufschiebt, nimmt man sie. Das haben wir getan. v1.9.0 wird gegen frisch deployte Factory- und Account-Implementation-Verträge ausgeliefert, die jede Empfehlung von Halborn übernehmen. Der stabile Branch des Repositorys @runonflux/account-abstraction ist nun main (npm ^1.1.0); der master-Branch und npm ~1.0.0 bleiben für alle verfügbar, die auf den älteren deployten Verträgen bleiben möchten.
Die BREAKING CHANGE für Ethereum- und Sepolia-Nutzer
Da die Factory diejenige Komponente ist, die eure Account-Adresse deterministisch aus euren öffentlichen Schlüsseln ableitet, bedeutet ein Re-Deploy der Factory, dass dieselben Schlüssel eine andere Adresse ableiten. Für Nutzer mit Geldern auf Ethereum Mainnet oder Sepolia ist das die praktische Folge von v1.9.0: Nach dem Update ist die Adresse, die SSP euch für Ethereum oder Sepolia anzeigt, eine neue. Eventuelles ETH oder ERC-20 an der alten Adresse bewegt sich nicht von selbst.
Es gibt zwei sichere Wege, damit umzugehen. Der einfache Weg ist, die Gelder vor dem Update von der alten Adresse wegzubewegen — schickt sie an ein anderes Wallet oder eine Exchange, dann aktualisiert, dann schickt sie an eure neue Adresse. Der andere Weg, für Nutzer, die bereits aktualisiert haben oder größere oder komplexere Positionen halten, ist, den SSP-Support für eine Migrationsanleitung zu kontaktieren, damit wir euch durch das Bergen der alten Gelder mit den alten Verträgen führen können.
UTXO-Chains sind nicht betroffen. Bitcoin-, Zcash-, Bitcoin-Cash- und Flux-Adressen werden aus euren Schlüsseln abgeleitet, ohne einen EVM-Vertrag zu durchlaufen, deshalb verändert v1.9.0 diese Adressen nicht. Es sind nur Ethereum und Sepolia betroffen.
Was als Nächstes kommt
Dieser Artikel deckt speziell das Audit der AA-Verträge ab, am Tag der Veröffentlichung. Die größere Geschichte — die vollständige Reihe der Halborn-Reviews über SSP Wallet, die Verträge und das SDK — wird in Inside SSPs Halborn-Audits 2025 erzählt, wo dieses Audit in den Kontext der anderen beiden gestellt wird.
Quelle: Release Notes zu SSP Wallet v1.9.0.