Multisig na EVM w stylu abstrakcji konta

Multisig jest prosty do opisania — wymagać więcej niż jednego podpisu, aby przenieść środki — ale sposób, w jaki się go buduje, znacząco różni się między blockchainami. W Bitcoinie multisig jest wbudowany w sam protokół. W Ethereum i innych łańcuchach EVM tak nie jest, a ten jeden fakt kształtuje to, jak działa każdy poważny portfel multisig na Ethereum, w tym SSP. Ten artykuł wyjaśnia, dlaczego multisig na EVM jest inny, prostym językiem oprowadza po narzędziach account abstraction, które go umożliwiają, i pokazuje dokładnie, jak SSP dostarcza prawdziwe 2-of-2 na Ethereum.

Jeśli trafiasz tu od początku serii EVM, Ethereum w SSP kładzie fundamenty; ten wpis to głębokie zanurzenie w mechanikę bezpieczeństwa leżącą pod spodem. Poziom lektury jest tu o stopień wyższy — średnio zaawansowany — bo oddanie tematowi sprawiedliwości oznacza uczciwe poruszenie ERC-4337 i agregacji podpisów, a nie ich omijanie.

Dlaczego multisig na EVM różni się od multisigu w Bitcoinie

Najczystszym sposobem zrozumienia SSP na Ethereum jest najpierw zobaczyć, dlaczego podejścia z Bitcoina nie da się po prostu przekopiować.

Bitcoin ma natywny skryptowy multisig. Protokół zawiera opcode, który pozwala zablokować środki za regułą w rodzaju „dowolne dwa z tych trzech kluczy publicznych muszą podpisać". Adres multisig w Bitcoinie to po prostu adres z dołączoną do niego regułą wydatkowania, a sieć egzekwuje ją bezpośrednio. SSP używa tego w Bitcoinie i innych łańcuchach UTXO poprzez skryptowy multisig BIP-48: dwa klucze, jeden skrypt, oba podpisy wymagane. Jeśli ten podstawowy model jest dla Ciebie nowy, czym jest multisig 2-of-2 to miejsce, od którego warto zacząć.

Ethereum nie ma odpowiednika. W łańcuchu EVM istnieją tylko dwa rodzaje kont. Pierwszy to EOA — konto należące do podmiotu zewnętrznego, kontrolowane przez dokładnie jeden klucz prywatny. Jeden klucz, jeden podpisujący, kropka; nie ma natywnego opcode, który wymagałby dwóch podpisów na EOA. Drugi to konto inteligentnego kontraktu, które zamiast jednego klucza kontrolującego ma kod i robi to, co ten kod nakazuje.

Dlatego na Ethereum „multisig" zawsze oznaczał portfel inteligentnego kontraktu: kontrakt zaprogramowany tak, by uwalniać środki dopiero wtedy, gdy spełniona jest jego reguła wielu podpisów. To model, który utorowały portfele takie jak Gnosis Safe / Safe, i działa on dobrze. Kompromisem jest to, że klasyczne kontrakty multisig on-chain zwykle przechowują podpis każdego właściciela i weryfikują je pojedynczo on-chain, co kosztuje gas i rośnie wraz z liczbą podpisujących. Account abstraction oferuje czystszą drogę i to właśnie tę drogę obiera SSP.

Krótkie i uczciwe wprowadzenie do ERC-4337

Account abstraction to idea, że Twój portfel powinien być inteligentnym kontraktem — programowalnym kontem — a nie zwykłą parą kluczy. ERC-4337 to standard, który dostarcza to na Ethereum bez zmiany protokołu bazowego. Nie musisz go opanować, by korzystać z SSP, ale kilka terminów sprawia, że reszta tego artykułu wskakuje na swoje miejsce. Pełne omówienie znajdziesz w czym jest account abstraction (ERC-4337); oto mapa na poziomie użytkownika.

• Smart account. Twoje środki znajdują się w smart account, którego kod definiuje, co liczy się jako prawidłowa transakcja. Ponieważ to kod, konto może egzekwować niestandardowe reguły — w tym „wymagać prawidłowego podpisu 2-of-2".
• UserOperation. Zamiast składać normalną transakcję, smart account wyraża swój zamiar jako UserOperation: ustrukturyzowane żądanie, które mówi, co chce zrobić, i niesie dane podpisu autoryzujące to działanie.
• Bundler. Bundler to usługa, która zbiera UserOperations, opakowuje je w prawdziwą transakcję on-chain i ją wysyła. Płaci gas z góry i otrzymuje zwrot; nigdy nie uzyskuje zdolności do przenoszenia Twoich środków.
• EntryPoint. Jeden poddany audytowi kontrakt EntryPoint jest zaufanym koordynatorem on-chain. Odbiera zgrupowane UserOperations i wywołuje każde smart account, by zweryfikować, a następnie wykonać jego operację.
• Paymaster. Opcjonalny kontrakt paymaster może sponsorować gas lub pozwalać, by opłaty były uiszczane w tokenie zamiast w monecie natywnej. Jest opcjonalny i niezależny od samego multisigu.

Kluczowy wniosek: ze smart account reguła „kto może autoryzować transakcję" to oprogramowanie, które kontrolujesz Ty, a nie stałe zachowanie protokołu. To właśnie ta wolność, której multisig potrzebuje w łańcuchu pozbawionym natywnego multisigu.

Jak SSP realizuje 2-of-2 na EVM

SSP dotrzymuje tej samej obietnicy w każdym wspieranym łańcuchu: dwa klucze na dwóch urządzeniach, i żadne z nich samo nie przeniesie Twoich pieniędzy. Klucz 1 znajduje się w rozszerzeniu przeglądarkowym SSP Wallet; klucz 2 znajduje się w aplikacji mobilnej SSP Key. Budujesz i podpisujesz transakcję w rozszerzeniu, a następnie zatwierdzasz ją na telefonie przez push — oba podpisy są wymagane.

W Bitcoinie ta gwarancja pochodzi ze skryptowego multisigu BIP-48. W łańcuchach EVM SSP odtwarza ją jako smart account ERC-4337, który weryfikuje agregowany podpis 2-of-2 Schnorra. Oto idea na wysokim poziomie, utrzymana ogólnie tam, gdzie dokładne wewnętrzne szczegóły kontraktu nie są istotą.

Każdy z Twoich dwóch kluczy wytwarza częściowy podpis nad transakcją. Zamiast wysyłać oba podpisy do łańcucha osobno, dwa urządzenia łączą je — używając agregacji podpisów w stylu MuSig2 — w jeden zwarty podpis. Smart account jest zaprogramowany tak, by przyjąć UserOperation tylko wtedy, gdy ten agregowany podpis weryfikuje się względem oczekiwanego klucza portfela. Łańcuch widzi więc zwyczajnie wyglądający podpis, a mimo to podpisu tego nie da się matematycznie wytworzyć bez udziału obu kluczy.

Ten projekt ma realne przewagi nad przechowywaniem i sprawdzaniem N osobnych podpisów on-chain:

• Mniejszy ślad on-chain. Jeden agregowany podpis jest tańszy w weryfikacji i przechowywaniu niż dwa niezależne, co zwykle oznacza mniej gasu za uzyskiwane bezpieczeństwo.
• UX identyczny jak w portfelu z jednym podpisującym. Ponieważ łańcuch waliduje pojedynczy podpis, Twój smart account zachowuje się z punktu widzenia sieci jak każde normalne konto. Wysyłanie ETH, przenoszenie tokenów ERC-20 czy interakcja z DeFi sprawiają to samo wrażenie — drugi podpis dzieje się dyskretnie między Twoimi dwoma urządzeniami.
• Ten sam model wszędzie. Schnorr i to podejście do agregacji opierają się na dobrze zbadanej kryptografii na secp256k1, a ten sam projekt smart account przenosi się na łańcuchy EVM wspierane przez SSP, w tym Ethereum, Polygon, Base, BNB Smart Chain i Avalanche.

Stojące za tym inteligentne kontrakty SSP zostały poddane audytowi przez Halborn w 2025 roku. Po głębszą mechanikę account abstraction — jak EntryPoint, bundler i krok walidacji do siebie pasują — sięgnij do wyjaśnienia account abstraction (ERC-4337), zamiast traktować jakikolwiek pojedynczy szczegół kontraktu tutaj jako kanoniczny.

Co to oznacza dla Ciebie jako użytkownika

Kryptografia jest ciekawa, ale na co dzień liczy się ochrona, którą ona kupuje.

• Do przeniesienia środków wymagane są oba urządzenia. Transakcja jest ważna dopiero wtedy, gdy rozszerzenie i SSP Key wniosły każde swoją część. Posiadanie jednego urządzenia — lub jednego klucza — nie wystarczy.
• Utrata jednego urządzenia to nie utrata Twoich pieniędzy. Ponieważ żadne pojedyncze urządzenie nie może podpisać samodzielnie, zgubiony lub wymazany telefon albo ponownie zainstalowana przeglądarka nie oddają nikomu kontroli nad Twoimi środkami. Przywracanie dostępu to osobny temat z własnymi zabezpieczeniami; odzyskiwanie jest omówione we własnych przewodnikach, nie tutaj.
• Pojedynczy skompromitowany klucz nie jest pojedynczym punktem awarii. Jeśli złośliwe oprogramowanie lub phishing przechwyci to, co jest na jednym urządzeniu, i tak nie może wytworzyć agregowanego podpisu 2-of-2, którego żąda smart account. Atakujący musiałby skompromitować oba Twoje urządzenia jednocześnie — to poprzeczka znacznie wyższa niż opróżnienie portfela z jednym kluczem.

To są ogólne zabezpieczenia, a nie gwarancje absolutne; dobra higiena frazy seed i bezpieczeństwo urządzenia wciąż mają znaczenie. Ale punkt strukturalny pozostaje w mocy: dwa niezależne czynniki muszą się zgodzić, zanim wartość się poruszy.

Neutralne porównanie z portfelami EOA z jednym kluczem

Większość portfeli Ethereum to EOA z jednym kluczem. Są proste i szeroko wspierane, a dla wielu użytkowników są w porządku. Kompromisem jest to, że jeden klucz prywatny stanowi całą historię: ktokolwiek go ma, może przenieść wszystko, więc jedna wyciekła fraza seed lub jedna skompromitowana maszyna mogą być fatalne.

Multisig inteligentnego kontraktu zmienia ten profil ryzyka, wymagając zgody między dwoma kluczami zamiast zaufania jednemu. Istnieją inne portfele multisig inteligentnego kontraktu — Safe to dobrze znany przykład — i rozwiązują ten sam podstawowy problem na swój sposób. Szczególnym wyborem SSP jest dostarczanie 2-of-2 poprzez ERC-4337 z agregowanym podpisem Schnorra, dzięki czemu otrzymujesz bezpieczeństwo multisigu ze śladem on-chain i codziennym odczuciem konta z jednym podpisującym.

Dokąd dalej

Jeśli chcesz koncepcyjnych podstaw, przeczytaj czym jest account abstraction (ERC-4337) oraz fundamentalne czym jest multisig 2-of-2. Aby zobaczyć, jak to wpisuje się w szerszy obraz Ethereum w SSP, wróć do Ethereum w SSP. A co do samego standardu, kanonicznymi źródłami są specyfikacja ERC-4337 oraz przegląd account abstraction Ethereum Foundation. Myśl przewodnia jest ta sama, która przewija się przez każdy łańcuch wspierany przez SSP: dwa klucze, dwa urządzenia, jeden podpis — i to Ty masz kontrolę.