Am 18. Juli 2024 fügte SSP Wallet v1.6.0 Ethereum hinzu — und SSP wurde das erste Wallet, das echte Schnorr-Multisig-Konten auf Ethereum mit ERC-4337 Account Abstraction ausliefert. Andere Wallets nennen sich "Ethereum-Multisig", indem sie ein einzelnes extern besessenes Konto hinter eine Benutzeroberfläche stellen. SSP hat den schwereren Weg gewählt, damit dasselbe 2-aus-2-Modell, das Bitcoin innerhalb von SSP schützt, nun auch ETH schützt.
TL;DR
- Ethereum (ETH) kommt als vollwertige Chain zu SSP.
- Konten sind Smart Contracts nach ERC-4337, keine EOAs — somit lebt die 2-aus-2-Durchsetzung on-chain.
- Zwei Schnorr-Signaturen aggregieren zu einer, bevor sie Ethereum erreichen, und halten das Gas vorhersehbar.
- Die Signaturbibliothek ist Open Source auf npm:
@runonflux/aa-schnorr-multisig-sdk. - ERC-20-Token-Unterstützung ist der nächste Schritt; diese Version liefert ETH selbst plus die AA-Grundlagen darunter.
Was gelandet ist: Ethereum-Unterstützung, auf die harte Tour
Die meisten Wallets "unterstützen Ethereum", indem sie ein extern besessenes Konto (EOA) erzeugen — ein einziger privater Schlüssel, eine einzige Signatur, ein einziger Ausfallpunkt. Multisig obendrauf bedeutet meist eine Software-Policy auf Wallet-Seite, keine durch die Chain erzwungene Regel. Die Chain sieht weiterhin einen Schlüssel, und wer ihn hält, kann Mittel allein bewegen.
SSP hat diese Abkürzung verweigert. Der ganze Sinn des 2-aus-2-Modells von SSP ist, dass weder SSP Wallet auf dem Desktop noch SSP Key auf dem Telefon Mittel allein bewegen können — Co-Signatur ist eine Eigenschaft des Kontos, keine UI-Konvention. Um das auf Ethereum zu erhalten, war eine EOA nie genug. Das Ethereum-Konto musste ein Smart Contract sein, der zwei Signaturen per Konstruktion verlangt. Genau das wurde in v1.6.0 ausgeliefert.
Was Schnorr-Multisig hier bedeutet
Bitcoins UTXO-Skripte können 2-aus-2 nativ ausdrücken — so erzwingen SSPs bestehende Chains die Co-Signatur. Ethereums Kontomodell kann das nicht, nicht ohne Hilfe. SSP schließt diese Lücke mit Schnorr-Signaturen.
Schnorr ist ein Signaturschema mit einer Eigenschaft, die hier zählt: zwei Unterzeichner können jeweils eine Teilsignatur erzeugen, und diese Teilsignaturen lassen sich zu einer einzigen, gültigen Signatur kombinieren, die unter einem einzelnen aggregierten öffentlichen Schlüssel verifiziert. Für jeden, der die Chain liest, sieht es so aus, als hätte ein einzelner Unterzeichner einmal signiert. Für SSP mussten zwei Geräte zustimmen. Die kryptographische Tiefe — Schlüssel-Aggregation, Nonce-Koordination, Runden im MuSig2-Stil — ist in unserem Academy-Beitrag über Schnorr-Signaturen und Multisig-Aggregation behandelt, falls gewünscht. Die nutzerseitige Zusammenfassung ist kurz: derselbe SSP Wallet + SSP Key Handshake, den du bereits nutzt, jetzt ausgedrückt als eine aggregierte Schnorr-Signatur auf Ethereum.
ERC-4337 Account Abstraction
Account Abstraction (AA) ist der Sammelbegriff dafür, dass Ethereum-Konten sich wie programmierbare Wallets statt als bloße Schlüsselpaare verhalten. Unter dem Standard-Ethereum-Modell gibt es zwei Kontotypen: EOAs, kontrolliert durch einen einzelnen privaten Schlüssel, und Contracts, die selbst keine Transaktionen anstoßen können. AA hebt diese Unterscheidung auf der Anwendungsebene auf.
ERC-4337 ist der Ethereum-Standard, der AA liefert, ohne Ethereum selbst zu ändern. Statt eines Hard Forks definiert er ein höherstufiges Transaktionsobjekt namens UserOperation, einen Bundler, der diese in normale Ethereum-Transaktionen verwandelt, und einen EntryPoint-Contract, der sie validiert. Dein "Konto" ist ein Smart Contract, der entscheidet, wie er Ausgaben authentifizieren will — für SSP lautet diese Authentifizierungsregel: eine aggregierte Schnorr-Signatur von SSP Wallet und SSP Key, oder nichts. Kein L1-Hard-Fork, keine speziellen Node-Operatoren, keine Vertrauensannahmen jenseits dessen, was bereits auf Mainnet deployed ist.
Die Open-Source-Bibliothek
Die Schnorr-Multisig-Signaturschicht ist nicht in der SSP-App vergraben. Wir haben sie als wiederverwendbare Bibliothek extrahiert und unter derselben Open-Source-Haltung wie der Rest von SSP veröffentlicht. Das TypeScript-SDK lebt auf npm als @runonflux/aa-schnorr-multisig-sdk; die zugehörigen Solidity-Account-Abstraction-Verträge leben im Repository @runonflux/account-abstraction auf GitHub.
Wenn du Wallet-Entwickler, Sicherheitsforscher oder schlicht neugierig bist, wie sich Schnorr-Multisig-AA auf Ethereum tatsächlich zusammensetzt, sind beide Projekte da, um gelesen, geforkt und mit Beiträgen versehen zu werden. Pull Requests und Issues sind willkommen — wir härten lieber eine geteilte Bibliothek mit mehr Augen ab, als jede Wallet, die dieses Primitiv möchte, sie neu erfinden zu lassen.
Was das freischaltet
Speziell für v1.6.0 ist die angebotene Chain Ethereum selbst — ETH-Guthaben, ETH-Überweisungen, derselbe Chains-Panel-Schalter, den du für jede andere Münze nutzt, jetzt mit einem AA-Konto dahinter. Die Klempnerei, die diese Version legt, ist der härtere Teil. Sobald 2-aus-2-Schnorr-AA-Konten existieren und funktionieren, wird jeder Ethereum-förmige Guthabentyp erreichbar.
ERC-20-Token-Unterstützung ist der natürliche nächste Schritt und steht bereits auf der Roadmap — wir behandeln sie in einem eigenen Newsroom-Beitrag, wenn sie kommt. Für heute ist die Schlagzeile: Ethereum ist in SSP, es ist auf die richtige Weise in SSP, und die darunterliegenden kryptographischen und Smart-Contract-Grundlagen sind Open Source auf npm und GitHub, damit jeder sie inspizieren kann.
Quelle: SSP Wallet v1.6.0 Release Notes.