Ein Blick in SSPs Account-Abstraction-Architektur

SSP ist eine selbstverwahrende Wallet, die um ein 2-of-2-multisig herum aufgebaut ist. Ein Schlüssel liegt in der SSP-Wallet-Browser-Erweiterung, der zweite in der SSP-Key-Mobil-App, und keine Transaktion wird abgeschlossen, solange nicht beide Geräte sie freigeben. Auf EVM-Ketten löst SSP diese Garantie mit ERC-4337-account-abstraction ein: Die Wallet ist ein smart account, dessen Validierungslogik eine einzige aus beiden Schlüsseln gebildete Schnorr-Aggregatsignatur akzeptiert. Dieser Artikel geht diese Architektur von Anfang bis Ende durch — jede Komponente, den genauen Signaturablauf und die Sicherheitseigenschaft, die er erzeugt.

Falls account abstraction für Sie neu ist, beginnen Sie mit Account Abstraction von Grund auf und der fokussierten ERC-4337-Erklärung. Hier setzen wir voraus, dass Sie ungefähr wissen, was ein smart account und eine UserOperation sind, und konzentrieren uns darauf, wie SSP sie miteinander verdrahtet.

Die Bausteine, auf die SSP setzt

Bevor wir den Ablauf nachzeichnen, hilft es, die Komponenten und ihre jeweilige Aufgabe zu benennen:

• Der smart account. Auf EVM-Ketten ist Ihre SSP-Wallet kein von einem einzigen Schlüssel kontrolliertes EOA. Sie ist ein ERC-4337-smart-account — ein Vertrag, der Ihre Mittel hält und seine eigene Validierungslogik enthält. Diese Logik ist das Herzstück des Entwurfs: Sie akzeptiert eine Transaktion nur dann, wenn die gelieferte Signatur zum erwarteten Aggregatschlüssel der Wallet passt.
• Die beiden Geräte. Schlüssel 1 liegt in der SSP-Wallet-Browser-Erweiterung. Schlüssel 2 liegt in der SSP-Key-Mobil-App. Jedes Gerät hält einen Anteil und erzeugt eine Teilsignatur. Kein Anteil kann allein irgendetwas autorisieren.
• Die UserOperation. Statt einer normalen Transaktion drückt die Erweiterung Ihre Absicht als UserOperation aus — ein strukturiertes Objekt, das beschreibt, was der account tun soll, und die Signatur, die es autorisiert.
• Der bundler. Ein bundler holt die UserOperation aus dem dafür vorgesehenen mempool, packt sie in eine echte On-Chain-Transaktion und zahlt das gas der Basisschicht, um sie einzureichen.
• Der EntryPoint. Ein einziger geprüfter EntryPoint-Vertrag ist der On-Chain-Eingang für jede ERC-4337-Operation. Er ruft Ihren smart account auf, um dessen eigene Validierungslogik auszuführen, und stößt dann die Ausführung an, wenn die Validierung besteht.

Ein paymaster kann optional das gas für eine UserOperation übernehmen; das ist ein eigenes Thema, behandelt in Gas-Sponsoring und Paymaster erklärt.

Der genaue Signaturablauf

Folgendes passiert Schritt für Schritt, wenn Sie eine Transaktion aus SSP auf einer EVM-Kette senden:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Als Fließtext gelesen:

1. Sie initiieren eine Transaktion in der SSP-Wallet-Browser-Erweiterung, die Schlüssel 1 hält.
2. Die Erweiterung baut eine ERC-4337-UserOperation, die die Aktion beschreibt.
3. Schlüssel 1 erzeugt eine partielle Schnorr-Signatur über diese Operation.
4. Die Anfrage wird zur Freigabe an die SSP-Key-Mobil-App gepusht (Schlüssel 2).
5. Schlüssel 2 erzeugt seine eigene Teilsignatur.
6. Die beiden Teilsignaturen werden MuSig2-artig über secp256k1 zu einer Schnorr-Signatur aggregiert.
7. Die UserOperation, die nun diese einzige Aggregatsignatur trägt, ist bereit zum Versand.
8. Sie geht an einen bundler, der sie in eine Transaktion packt und das gas zahlt.
9. Der bundler reicht sie beim EntryPoint-Vertrag ein, der SSPs smart account aufruft. Der account validiert die einzige Aggregatsignatur gegen den erwarteten Aggregatschlüssel der Wallet und führt, falls gültig, den Aufruf aus.

Beide Geräte sind nötig, um Schritt 6 zu erreichen, und genau das macht dies zu einem echten 2-of-2. Entfernen Sie eine der Teilsignaturen, und die Aggregation kann keine Signatur erzeugen, die der Vertrag akzeptiert.

Warum die Kette nur eine Signatur sieht

Das Detail, das SSPs Entwurf elegant macht, ist die Aggregation in Schritt 6. Die Erweiterung und das Telefon hängen nicht jeweils eine separate Signatur an die Operation. Ihre beiden partiellen Schnorr-Signaturen verbinden sich — MuSig2-artig, über dieselbe secp256k1-Kurve, die Ethereum bereits verwendet — zu einer einzigen Schnorr-Signatur. Der smart account prüft diese eine Signatur gegen einen einzigen erwarteten Aggregatschlüssel.

Das hat zwei Folgen, bei denen es sich zu verweilen lohnt:

• Der On-Chain-Fußabdruck bleibt klein. Die UserOperation trägt eine Signatur, nicht zwei. Es gibt keine zu speichernde oder zu durchlaufende Unterzeichnerliste und keine Prüfschleife pro Unterzeichner. Der Vertrag leistet dieselbe Menge an Validierungsarbeit wie für einen einzigen Unterzeichner.
• Die Kette kann nicht erkennen, dass es multisig ist. Was beim EntryPoint ankommt, sieht aus wie eine gewöhnliche signierte Operation. Die 2-of-2-Durchsetzung steckt darin, wie die Signatur erzeugt wurde — über zwei Geräte hinweg — und nicht in irgendeiner sichtbaren mehrparteiigen Struktur auf der Kette. Für einen externen Beobachter verhält sich die Wallet wie jeder andere smart account.

Das ist der Unterschied zwischen SSPs Ansatz und einem naiven multisig, das N separate Signaturen veröffentlicht und jede einzeln prüft. Die Mechanik, multisig auf EVM auf diese Weise umzusetzen, wird in EVM-Multisig nach Art der Account Abstraction weiter vertieft.

Was jedes Gerät tatsächlich schützt

Es lohnt sich, bei der Sicherheitseigenschaft präzise zu sein, denn sie ist der ganze Sinn der Architektur.

• Kein Schlüssel kann allein Mittel bewegen. Schlüssel 1 in der Erweiterung kann eine UserOperation bauen und seine Hälfte signieren, doch eine halbe Signatur aggregiert zu etwas, das der Vertrag nicht akzeptiert. Schlüssel 2 auf dem Telefon kann freigeben und seine Hälfte signieren, kann aber einen Transfer nicht im Alleingang anstoßen oder abschließen.
• Die Kompromittierung eines Geräts reicht nicht. Ein Angreifer, der Ihre Browser-Erweiterung vollständig kontrolliert, kann dennoch nichts ausgeben, weil er ohne das Telefon die Teilsignatur von Schlüssel 2 nicht erzeugen kann. Das Umgekehrte gilt ebenso. Das Bedrohungsmodell, das ein Einzelschlüssel-EOA nicht übersteht — ein durchgesickerter Schlüssel, Totalverlust — trifft hier nicht zu.
• Die Freigabe ist explizit und auf einem zweiten Bildschirm. Da Schritt 4 die Anfrage an die SSP-Key-App pusht, sehen und genehmigen Sie die Operation auf einem physisch getrennten Gerät, bevor sie aggregiert und gesendet werden kann.

Das ist dieselbe 2-of-2-Eigenschaft, die in Was ist 2-of-2-Multisig? beschrieben wird, auf EVM-Ketten über account abstraction statt über einen nativen multisig-Opcode realisiert.

Die Vorteile, zusammengefasst

Fasst man die Fäden zusammen, verschafft die Architektur SSP-Nutzern eine bestimmte Kombination, die anderswo schwer zu bekommen ist:

• Multisig-Sicherheit auf jeder unterstützten EVM-Kette. Derselbe 2-of-2-Entwurf läuft auf Ethereum, Polygon, Base, BNB Smart Chain und Avalanche, weil ERC-4337 ein Standard auf Vertragsebene und kein kettenspezifisches Feature ist.
• Ein kleiner On-Chain-Fußabdruck. Eine einzige Aggregatsignatur bedeutet, dass der smart account wie ein einziger Unterzeichner validiert, was die Prüfung schlank hält.
• UX wie bei einem einzigen Unterzeichner. Aus Ihrer Sicht fühlt es sich an, als würden Sie eine Transaktion auf zwei Geräten freigeben, nicht als würden Sie ein Gremium zusammenstellen. Es gibt keine zu verwaltenden Mitunterzeichneradressen und keinen separaten multisig-Vertrag, der pro Transfer konfiguriert werden müsste.
• Keine Protokolländerungen erforderlich. Da alles auf ERC-4337 aufsetzt, erhält SSP all dies, ohne darauf zu warten, dass account abstraction auf der Basisschicht ausgeliefert wird.

Eine Anmerkung zur Prüfung

Eine Sicherheitsarchitektur ist nur so vertrauenswürdig wie ihre Überprüfung. SSPs smart contracts wurden 2025 von Halborn geprüft. Eine externe Prüfung macht kein System fehlerfrei, aber sie ist ein aussagekräftiges Vertrauenssignal für die Vertragslogik, die die oben beschriebene 2-of-2-Regel durchsetzt.

Wohin als Nächstes

Dieser Artikel hat SSPs account abstraction von Anfang bis Ende nachgezeichnet. Um beim umgebenden Standard und den Konzepten tiefer zu gehen:

• Account Abstraction von Grund auf — warum EOAs einschränkend sind und was account abstraction bedeutet.
• Was ist Account Abstraction (ERC-4337)? — der Standard für sich genommen, einschließlich der Rollen von UserOperation, bundler und EntryPoint.
• Gas-Sponsoring und Paymaster erklärt — wie ein paymaster das gas für eine UserOperation übernehmen kann.
• EVM-Multisig nach Art der Account Abstraction — die multisig-Mechanik auf EVM ausführlicher.

Die formale Spezifikation finden Sie in EIP-4337; für die breitere Bemühung verfolgt Ethereums Account-Abstraction-Roadmap, wohin es geht. Die Quintessenz: SSP verwandelt das abstrakte Versprechen eines programmierbaren account in eine konkrete 2-of-2-Wallet, in der zwei Geräte eine Signatur erzeugen und die Kette schlicht eine gültige Operation sieht.