Wewnątrz architektury abstrakcji kont SSP

SSP to samodzielnie przechowujący portfel zbudowany wokół multisig 2-z-2. Jeden klucz znajduje się w rozszerzeniu przeglądarki SSP Wallet, drugi w aplikacji mobilnej SSP Key, a żadna transakcja nie zostaje rozliczona, dopóki nie zatwierdzą jej oba urządzenia. Na łańcuchach EVM SSP realizuje tę gwarancję za pomocą account abstraction z ERC-4337: portfel jest smart accountem, którego logika walidacji przyjmuje pojedynczy zagregowany podpis Schnorr zbudowany z dwóch kluczy. Ten artykuł przechodzi przez tę architekturę od początku do końca — każdy komponent, dokładny przepływ podpisywania i właściwość bezpieczeństwa, którą on wytwarza.

Jeśli account abstraction jest dla Ciebie nowością, zacznij od Abstrakcja kont od pierwszych zasad i ukierunkowanego wyjaśnienia ERC-4337. Tutaj zakładamy, że z grubsza wiesz, czym są smart account i UserOperation, i skupiamy się na tym, jak SSP łączy je ze sobą.

Elementy, na których opiera się SSP

Zanim prześledzimy przepływ, warto nazwać komponenty i to, co robi każdy z nich:

• Smart account. Na łańcuchach EVM Twój portfel SSP nie jest EOA kontrolowanym przez jeden klucz. Jest smart accountem ERC-4337 — kontraktem, który przechowuje Twoje środki i zawiera własną logikę walidacji. Ta logika jest sercem projektu: przyjmuje transakcję tylko wtedy, gdy dostarczony podpis pasuje do oczekiwanego klucza zagregowanego portfela.
• Dwa urządzenia. Klucz 1 znajduje się w rozszerzeniu przeglądarki SSP Wallet. Klucz 2 znajduje się w aplikacji mobilnej SSP Key. Każde urządzenie przechowuje jeden udział i wytwarza jeden podpis częściowy. Żaden udział nie może niczego autoryzować w pojedynkę.
• UserOperation. Zamiast zwykłej transakcji rozszerzenie wyraża Twój zamiar jako UserOperation — uporządkowany obiekt opisujący, co account ma zrobić, oraz podpis, który to autoryzuje.
• Bundler. Bundler pobiera UserOperation z dedykowanego mempoola, pakuje ją w rzeczywistą transakcję on-chain i płaci gas warstwy bazowej, aby ją przesłać.
• EntryPoint. Pojedynczy, poddany audytowi kontrakt EntryPoint jest on-chainowym wejściem dla każdej operacji ERC-4337. Wywołuje Twój smart account, aby uruchomić logikę walidacji tego accounta, a następnie uruchamia wykonanie, jeśli walidacja przejdzie.

paymaster może opcjonalnie pokryć gas dla UserOperation; to osobny temat, omówiony w Sponsorowanie gas i paymastery wyjaśnione.

Dokładny przepływ podpisywania

Oto co dzieje się krok po kroku, gdy wysyłasz transakcję z SSP na łańcuchu EVM:

  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

Odczytane jako proza:

1. Inicjujesz transakcję w rozszerzeniu przeglądarki SSP Wallet, które przechowuje klucz 1.
2. Rozszerzenie buduje UserOperation ERC-4337 opisującą działanie.
3. Klucz 1 wytwarza częściowy podpis Schnorr nad tą operacją.
4. Żądanie zostaje wypchnięte do aplikacji mobilnej SSP Key (klucz 2) do zatwierdzenia.
5. Klucz 2 wytwarza własny podpis częściowy.
6. Dwa podpisy częściowe zostają zagregowane, w stylu MuSig2 nad secp256k1, w jeden podpis Schnorr.
7. UserOperation, niosąca teraz ten pojedynczy zagregowany podpis, jest gotowa do wysłania.
8. Trafia do bundlera, który pakuje ją w transakcję i płaci gas.
9. Bundler przesyła ją do kontraktu EntryPoint, który wywołuje smart account SSP. Account waliduje pojedynczy zagregowany podpis względem oczekiwanego klucza zagregowanego portfela i, jeśli jest prawidłowy, wykonuje wywołanie.

Oba urządzenia są potrzebne, aby dotrzeć do kroku 6, i właśnie to czyni z tego prawdziwe 2-z-2. Usuń którykolwiek z podpisów częściowych, a agregacja nie zdoła wytworzyć podpisu, który kontrakt zaakceptuje.

Dlaczego łańcuch widzi tylko jeden podpis

Szczegół, który czyni projekt SSP eleganckim, to agregacja w kroku 6. Rozszerzenie i telefon nie dołączają każde osobnego podpisu do operacji. Ich dwa częściowe podpisy Schnorr łączą się — w stylu MuSig2, nad tą samą krzywą secp256k1, której Ethereum już używa — w jeden podpis Schnorr. Smart account sprawdza ten jeden podpis względem jednego oczekiwanego klucza zagregowanego.

Ma to dwie konsekwencje, przy których warto się zatrzymać:

• Ślad on-chain pozostaje mały. UserOperation niesie jeden podpis, nie dwa. Nie ma listy sygnatariuszy do przechowywania ani przeglądania, nie ma pętli weryfikacji na każdego sygnatariusza. Kontrakt wykonuje tę samą ilość pracy walidacyjnej, jaką wykonałby dla pojedynczego sygnatariusza.
• Łańcuch nie potrafi rozpoznać, że to multisig. To, co trafia do EntryPoint, wygląda jak zwykła podpisana operacja. Egzekwowanie 2-z-2 tkwi w tym, jak podpis został wytworzony — na dwóch urządzeniach — a nie w jakiejś widocznej na łańcuchu wielostronnej strukturze. Dla zewnętrznego obserwatora portfel zachowuje się jak każdy inny smart account.

To właśnie różnica między podejściem SSP a naiwnym multisig, który publikuje N osobnych podpisów i weryfikuje każdy z nich. Mechanika robienia multisig w ten sposób na EVM jest pogłębiona w Multisig na EVM w stylu abstrakcji kont.

Co tak naprawdę chroni każde urządzenie

Warto być precyzyjnym co do właściwości bezpieczeństwa, ponieważ jest ona całym sensem tej architektury.

• Żaden klucz w pojedynkę nie może poruszyć środków. Klucz 1 w rozszerzeniu może zbudować UserOperation i podpisać swoją połowę, ale pół podpisu agreguje się w coś, czego kontrakt nie zaakceptuje. Klucz 2 w telefonie może zatwierdzić i podpisać swoją połowę, ale nie może samodzielnie zainicjować ani dokończyć przelewu.
• Skompromitowanie jednego urządzenia nie wystarczy. Atakujący, który w pełni kontroluje Twoje rozszerzenie przeglądarki, wciąż nie może wydać środków, ponieważ bez telefonu nie potrafi wytworzyć podpisu częściowego klucza 2. Działa to też w drugą stronę. Model zagrożenia, którego jednokluczowe EOA nie przetrwa — jeden wyciekły klucz, całkowita strata — tutaj nie obowiązuje.
• Zatwierdzenie jest jawne i na drugim ekranie. Ponieważ krok 4 wypycha żądanie do aplikacji SSP Key, widzisz i zatwierdzasz operację na fizycznie oddzielnym urządzeniu, zanim będzie mogła zostać zagregowana i wysłana.

To ta sama właściwość 2-z-2 opisana w Czym jest multisig 2-z-2?, zrealizowana na łańcuchach EVM poprzez abstrakcję kont, a nie natywny opcode multisig.

Korzyści w skrócie

Łącząc wątki, architektura zapewnia użytkownikom SSP konkretne połączenie, które trudno uzyskać w inny sposób:

• Bezpieczeństwo multisig na każdym wspieranym łańcuchu EVM. Ten sam projekt 2-z-2 działa na Ethereum, Polygon, Base, BNB Smart Chain i Avalanche, ponieważ ERC-4337 jest standardem na poziomie kontraktu, a nie funkcją specyficzną dla łańcucha.
• Mały ślad on-chain. Pojedynczy zagregowany podpis oznacza, że smart account waliduje jak pojedynczy sygnatariusz, utrzymując weryfikację szczupłą.
• UX jak u pojedynczego sygnatariusza. Z Twojej strony przypomina to zatwierdzanie transakcji na dwóch urządzeniach, a nie składanie komitetu. Nie ma adresów współsygnatariuszy do zarządzania ani osobnego kontraktu multisig do skonfigurowania przy każdym przelewie.
• Nie są wymagane żadne zmiany protokołu. Ponieważ wszystko opiera się na ERC-4337, SSP uzyskuje to wszystko bez czekania, aż abstrakcja kont na warstwie bazowej zostanie wdrożona.

Słowo o audycie

Architektura bezpieczeństwa jest wiarygodna tylko na tyle, na ile została zweryfikowana. Smart contracts SSP zostały poddane audytowi przez Halborn w 2025 roku. Audyt zewnętrzny nie czyni żadnego systemu nieomylnym, ale jest znaczącym sygnałem zaufania dla logiki kontraktu, która egzekwuje opisaną wyżej regułę 2-z-2.

Dokąd dalej

Ten artykuł prześledził abstrakcję kont SSP od początku do końca. Aby zagłębić się w otaczający standard i pojęcia:

• Abstrakcja kont od pierwszych zasad — dlaczego EOA są ograniczające i co oznacza abstrakcja kont.
• Czym jest abstrakcja kont (ERC-4337)? — standard w izolacji, łącznie z rolami UserOperation, bundlera i EntryPoint.
• Sponsorowanie gas i paymastery wyjaśnione — jak paymaster może pokryć gas dla UserOperation.
• Multisig na EVM w stylu abstrakcji kont — mechanika multisig na EVM bardziej szczegółowo.

Po formalną specyfikację sięgnij do EIP-4337; jeśli chodzi o szerszy wysiłek, mapa drogowa abstrakcji kont Ethereum śledzi, dokąd to zmierza. Wniosek: SSP zamienia abstrakcyjną obietnicę programowalnego account w konkretny portfel 2-z-2, w którym dwa urządzenia wytwarzają jeden podpis, a łańcuch widzi po prostu prawidłową operację.