EVM multisig auf die Art der Account Abstraction
Multisig ist einfach zu beschreiben — mehr als eine Signatur verlangen, um Guthaben zu bewegen — doch die Art, wie es gebaut wird, unterscheidet sich erheblich zwischen Blockchains. Bei Bitcoin ist multisig im Protokoll selbst verankert. Bei Ethereum und anderen EVM-Chains ist es das nicht, und allein diese Tatsache prägt, wie jede ernsthafte multisig-Wallet auf Ethereum funktioniert, SSP eingeschlossen. Dieser Artikel erklärt, warum multisig auf EVM anders ist, gibt einen Rundgang in einfacher Sprache durch die Account-abstraction-Werkzeuge, die es möglich machen, und zeigt genau, wie SSP ein echtes 2-of-2 auf Ethereum liefert.
Wenn Sie vom Anfang der EVM-Reihe hierhergekommen sind: Ethereum in SSP legt das Fundament; dieser Beitrag ist der Tiefgang in die Sicherheitsmechanik darunter. Das Leseniveau liegt hier eine Stufe höher — fortgeschritten — denn dem Thema gerecht zu werden, heißt, ERC-4337 und die Signaturaggregation ehrlich anzufassen, statt um sie herumzureden.
Warum sich multisig auf EVM von multisig bei Bitcoin unterscheidet
Der klarste Weg, SSP auf Ethereum zu verstehen, ist, zuerst zu sehen, warum sich der Bitcoin-Ansatz nicht einfach übertragen lässt.
Bitcoin hat natives Skript-multisig. Das Protokoll enthält einen Opcode, mit dem Sie Guthaben hinter einer Regel wie „beliebige zwei dieser drei öffentlichen Schlüssel müssen signieren" sperren können. Eine multisig-Adresse bei Bitcoin ist lediglich eine Adresse mit dieser angehängten Ausgaberegel, und das Netzwerk setzt sie direkt durch. SSP nutzt das bei Bitcoin und den übrigen UTXO-Chains über BIP-48-Skript-multisig: zwei Schlüssel, ein Skript, beide Signaturen erforderlich. Falls Ihnen dieses Grundmodell neu ist, ist was ist 2-of-2 multisig der richtige Ausgangspunkt.
Ethereum hat kein Äquivalent. Auf einer EVM-Chain gibt es nur zwei Arten von Konten. Das erste ist ein EOA — ein extern besessenes Konto, kontrolliert von genau einem privaten Schlüssel. Ein Schlüssel, ein Unterzeichner, Punkt; es gibt keinen nativen Opcode, um zwei Signaturen auf einem EOA zu verlangen. Das zweite ist ein Smart-Contract-Konto, das anstelle eines einzigen kontrollierenden Schlüssels Code besitzt und das tut, was dieser Code vorgibt.
Auf Ethereum bedeutete „multisig" daher stets eine Smart-Contract-Wallet: ein Contract, der so programmiert ist, dass er Guthaben nur freigibt, wenn seine Mehrfachsignatur-Regel erfüllt ist. Das ist das Modell, das Wallets wie Gnosis Safe / Safe geprägt haben, und es funktioniert gut. Der Kompromiss ist, dass klassische On-Chain-multisig-Contracts typischerweise die Signatur jedes Eigentümers speichern und sie einzeln on-chain prüfen, was gas kostet und mit der Zahl der Unterzeichner wächst. Account abstraction bietet einen saubereren Weg, und genau diesen Weg geht SSP.
Eine kurze, ehrliche Einführung in ERC-4337
Account abstraction ist die Idee, dass Ihre Wallet ein Smart Contract sein sollte — ein programmierbares Konto — statt eines schlichten Schlüsselpaars. ERC-4337 ist der Standard, der das auf Ethereum liefert, ohne das Basisprotokoll zu ändern. Sie müssen ihn nicht beherrschen, um SSP zu nutzen, aber ein paar Begriffe lassen den Rest dieses Artikels einrasten. Für die vollständige Behandlung lesen Sie was ist account abstraction (ERC-4337); hier die Landkarte auf Nutzerebene.
- Smart account. Ihr Guthaben liegt in einem smart account, dessen Code definiert, was als gültige Transaktion zählt. Weil es Code ist, kann das Konto eigene Regeln durchsetzen — darunter „eine gültige 2-of-2-Signatur verlangen".
- UserOperation. Statt eine normale Transaktion einzureichen, drückt ein smart account seine Absicht als UserOperation aus: eine strukturierte Anfrage, die sagt, was er tun will, und die Signaturdaten trägt, die das autorisieren.
- Bundler. Ein bundler ist ein Dienst, der UserOperations sammelt, sie in eine echte On-Chain-Transaktion verpackt und einreicht. Er zahlt das gas im Voraus und wird erstattet; er erlangt nie die Fähigkeit, Ihr Guthaben zu bewegen.
- EntryPoint. Ein einziger, geprüfter EntryPoint-Contract ist der vertrauenswürdige On-Chain-Koordinator. Er empfängt die gebündelten UserOperations und ruft jedes smart account auf, um dessen Operation zu validieren und dann auszuführen.
- Paymaster. Ein optionaler paymaster-Contract kann gas sponsern oder erlauben, dass Gebühren in einem Token statt der nativen Münze gezahlt werden. Er ist optional und unabhängig vom multisig selbst.
Die entscheidende Einsicht: Mit einem smart account ist die Regel, „wer eine Transaktion autorisieren darf", von Ihnen kontrollierte Software, kein festes Protokollverhalten. Genau das ist die Freiheit, die multisig auf einer Chain ohne natives multisig braucht.
Wie SSP 2-of-2 auf EVM umsetzt
SSP hält auf jeder unterstützten Chain dasselbe Versprechen: zwei Schlüssel auf zwei Geräten, und keines davon kann allein Ihr Geld bewegen. Schlüssel 1 liegt in der SSP-Wallet-Browser-Erweiterung; Schlüssel 2 liegt in der SSP-Key-Mobil-App. Sie erstellen und signieren eine Transaktion in der Erweiterung und genehmigen sie dann auf Ihrem Telefon per push — beide Signaturen sind erforderlich.
Bei Bitcoin kommt diese Garantie vom BIP-48-Skript-multisig. Auf EVM-Chains bildet SSP sie als ERC-4337 smart account nach, das eine Schnorr-aggregierte 2-of-2-Signatur prüft. Hier ist die Idee auf hohem Niveau, allgemein gehalten dort, wo die genauen Contract-Interna nicht der Punkt sind.
Jeder Ihrer beiden Schlüssel erzeugt eine Teilsignatur über die Transaktion. Statt beide Signaturen getrennt an die Chain zu senden, kombinieren die beiden Geräte sie — mittels Signaturaggregation im MuSig2-Stil — zu einer einzigen, kompakten Signatur. Das smart account ist so programmiert, dass es eine UserOperation nur akzeptiert, wenn diese aggregierte Signatur gegen den erwarteten Schlüssel der Wallet verifiziert. Die Chain sieht somit eine ganz gewöhnlich aussehende Signatur, und doch ist diese Signatur mathematisch unmöglich ohne die Beteiligung beider Schlüssel zu erzeugen.
Dieses Design hat echte Vorteile gegenüber dem Speichern und Prüfen von N getrennten Signaturen on-chain:
- Kleinerer On-Chain-Fußabdruck. Eine aggregierte Signatur ist günstiger zu verifizieren und zu speichern als zwei unabhängige, was tendenziell weniger gas für die Sicherheit bedeutet, die Sie erhalten.
- Identische UX zu einer Single-Signer-Wallet. Weil die Chain eine einzige Signatur validiert, verhält sich Ihr smart account aus Sicht des Netzwerks wie jedes normale Konto. ETH senden, ERC-20-Token bewegen oder mit DeFi interagieren fühlt sich gleich an — die zweite Signatur geschieht leise zwischen Ihren beiden Geräten.
- Dasselbe Modell überall. Schnorr und dieser Aggregationsansatz bauen auf gut untersuchter Kryptografie über secp256k1 auf, und dasselbe smart-account-Design überträgt sich auf die von SSP unterstützten EVM-Chains, darunter Ethereum, Polygon, Base, BNB Smart Chain und Avalanche.
Die SSP-Smart-Contracts dahinter wurden 2025 von Halborn geprüft. Für die tiefere Account-abstraction-Mechanik — wie EntryPoint, bundler und der Validierungsschritt zusammenpassen — greifen Sie auf die Erklärung account abstraction (ERC-4337) zurück, statt irgendein einzelnes Contract-Detail hier als kanonisch zu behandeln.
Was das für Sie als Nutzer bedeutet
Die Kryptografie ist interessant, aber was im Alltag zählt, ist der Schutz, den sie erkauft.
- Beide Geräte sind nötig, um Guthaben zu bewegen. Eine Transaktion ist erst gültig, sobald die Erweiterung und der SSP Key jeweils ihren Teil beigesteuert haben. Der Besitz eines Geräts — oder eines Schlüssels — genügt nicht.
- Ein Gerät zu verlieren heißt nicht, Ihr Geld zu verlieren. Da kein einzelnes Gerät allein signieren kann, übergibt ein verlorenes oder gelöschtes Telefon oder ein neu installierter Browser niemandem die Kontrolle über Ihr Guthaben. Den Zugriff wiederherzustellen ist ein eigenes Thema mit eigenen Schutzmaßnahmen; die Wiederherstellung wird in eigenen Leitfäden behandelt, nicht hier.
- Ein einzelner kompromittierter Schlüssel ist kein Single Point of Failure. Wenn Malware oder phishing erbeutet, was auf einem Gerät liegt, kann es dennoch nicht die aggregierte 2-of-2-Signatur erzeugen, die das smart account verlangt. Ein Angreifer müsste beide Ihrer Geräte zugleich kompromittieren — eine weit höhere Hürde, als eine Ein-Schlüssel-Wallet zu leeren.
Das sind allgemeine Schutzmaßnahmen, keine absoluten Garantien; gute seed-Phrase-Hygiene und Gerätesicherheit bleiben wichtig. Doch der strukturelle Punkt bleibt bestehen: Zwei unabhängige Faktoren müssen übereinstimmen, bevor sich Wert bewegt.
Ein neutraler Vergleich mit Ein-Schlüssel-EOA-Wallets
Die meisten Ethereum-Wallets sind Ein-Schlüssel-EOAs. Sie sind einfach und breit unterstützt, und für viele Nutzer sind sie in Ordnung. Der Kompromiss ist, dass ein privater Schlüssel die ganze Geschichte ist: Wer ihn hält, kann alles bewegen, sodass eine einzige geleakte seed-Phrase oder eine kompromittierte Maschine fatal sein kann.
Ein Smart-Contract-multisig verändert dieses Risikoprofil, indem es Übereinstimmung zwischen zwei Schlüsseln verlangt, statt einem zu vertrauen. Es gibt andere Smart-Contract-multisig-Wallets — Safe ist ein bekanntes Beispiel — und sie lösen dasselbe Kernproblem auf ihre Weise. Die besondere Wahl von SSP ist, 2-of-2 über ERC-4337 mit einer aggregierten Schnorr-Signatur zu liefern, sodass Sie multisig-Sicherheit mit dem On-Chain-Fußabdruck und dem Alltagsgefühl eines Single-Signer-Kontos erhalten.
Wohin als Nächstes
Wenn Sie das konzeptionelle Fundament wollen, lesen Sie was ist account abstraction (ERC-4337) und das grundlegende was ist 2-of-2 multisig. Um zu sehen, wie sich das in das größere Ethereum-Bild in SSP einfügt, kehren Sie zu Ethereum in SSP zurück. Und für den Standard selbst sind die kanonischen Quellen die ERC-4337-Spezifikation und der Überblick zur account abstraction der Ethereum Foundation. Der rote Faden ist derselbe, der sich durch jede von SSP unterstützte Chain zieht: zwei Schlüssel, zwei Geräte, eine Signatur — und Sie behalten die Kontrolle.
