Abstrakcja kont od pierwszych zasad

Jeśli kiedykolwiek korzystałeś z samodzielnie zarządzanego portfela na Ethereum, używałeś konta zewnętrznie posiadanego — EOA — niezależnie od tego, czy zdawałeś sobie z tego sprawę. Rozmowa o abstrakcji kont zaczyna się od zrozumienia, czym jest EOA, dlaczego jej konstrukcja ogranicza wszystko, co możesz zrobić on-chain, oraz jak abstrakcja kont ERC-4337 obchodzi te ograniczenia, nie ruszając protokołu bazowego. Ten artykuł jest punktem wejścia do serii, która prowadzi cię od pierwotnych ograniczeń aż do tego, jak SSP wykorzystuje abstrakcję kont, by uruchamiać swój multisig 2-z-2 na łańcuchach EVM.

To część fundamentalna i koncepcyjna. Aby skupić się na samym standardzie ERC-4337, przeczytaj Czym jest abstrakcja kont (ERC-4337)? razem z tym artykułem; tutaj budujemy intuicję tego, dlaczego ten standard istnieje.

Konto, które dało ci Ethereum

Ethereum ma dwa rodzaje kont. Konta kontraktowe są rządzone przez kod. EOA — zwykłe portfele, których używa większość ludzi — są rządzone przez jeden klucz prywatny. Kto posiada ten klucz, może autoryzować dowolną transakcję z konta, a protokół weryfikuje dokładnie jedną rzecz: że transakcja niesie ważny podpis ECDSA na krzywej secp256k1, wytworzony przez klucz kontrolujący adres.

Ta jedna reguła jest elegancka i jest zarazem źródłem każdego ograniczenia omówionego poniżej. Ważność transakcji jest na sztywno wpisana w protokół. Ty, właściciel konta, nie możesz decydować, co znaczy „ważna". Decyduje protokół, a on umie sprawdzić tylko jeden schemat podpisu jednego klucza.

Co ta konstrukcja wpisuje u podstaw

Cztery ograniczenia wynikają bezpośrednio z modelu jeden klucz, jeden podpis:

• Jeden klucz to pojedynczy punkt awarii. Zgub klucz, a środki przepadną. Ujawnij go, a atakujący ma wszystko. Na poziomie protokołu nie ma drugiego składnika, ani współpodpisującego, ani polityki, która mogłaby zablokować kradzież.
• Brak własnej logiki walidacji. EOA nie może powiedzieć „wymagaj dwóch podpisów", ani „pozwól na tę małą płatność automatycznie, ale powyżej progu wymagaj dodatkowej zgody", ani „pozwól temu kluczowi wydawać tylko w dni robocze". Konto nie ma logiki. Ma sprawdzenie podpisu.
• Nadawca musi posiadać ETH na gas. Każda transakcja EOA płaci własny gas w ETH. Nowy użytkownik, który ma tylko token ERC-20, ale żadnego ETH, nie może ruszyć tego tokena, bo nie może zapłacić opłaty. Płatnik opłaty i nadawca transakcji są zmuszeni być tym samym kontem.
• UX frazy seed jest bezlitosny. Ponieważ klucz jest kontem, rozpoczęcie oznacza spisanie frazy seed i chronienie jej na zawsze. Nie ma ścieżki odzyskiwania, która nie angażowałaby tej frazy, a jedna pomyłka jest nieodwracalna.

To nie są błędy. To konsekwencje tego, że walidacja mieszka w protokole, a nie w koncie.

Główny pomysł: uczynić konto programowalnym

Abstrakcja kont to pomysł wyniesienia tej logiki walidacji z protokołu do samego konta. Zamiast aby sieć kodowała na sztywno „transakcja jest ważna, jeśli ma jeden poprawny podpis ECDSA", smart account — kontrakt przechowujący twoje środki — sam decyduje, co liczy się jako ważna transakcja.

Gdy konto staje się programowalnym kontraktem, cztery ograniczenia rozpuszczają się w decyzje projektowe:

• Może wymagać dwóch podpisów zamiast jednego, co jest dokładnie tym, jak multisig staje się możliwy bez natywnego wsparcia protokołu.
• Może wdrożyć reguły odzyskiwania, tak że zgubiony klucz przestaje być końcem historii.
• Może pozwolić, by gas zapłacił ktoś inny, oddzielając płatnika opłaty od nadawcy.
• Może scalić kilka działań — na przykład zatwierdzenie i wymianę — w jedną atomową operację.

Konto przestaje być biernym kluczem i staje się programowalną logiką, którą kontrolujesz.

Jak ERC-4337 dostarcza to bez hard forka

Trudność polega na tym, że zmiana sposobu, w jaki Ethereum waliduje transakcje, zwykle oznacza zmianę protokołu bazowego — powolną, sporną, ogólnosieciową aktualizację. ERC-4337 całkowicie to omija. Wprowadza abstrakcję kont jako warstwę ponad istniejącą siecią, bez żadnych wymaganych zmian konsensusu.

Mechanizm opiera się na kilku elementach:

• UserOperations. Zamiast wysyłać zwykłą transakcję, smart account wyraża zamiar jako UserOperation — ustrukturyzowany obiekt opisujący, co konto chce zrobić i jak ma zostać zwalidowane.
• Alternatywny mempool. UserOperations żyją we własnym mempoolu, oddzielonym od zwykłych transakcji.
• Bundlers. Bundler zbiera UserOperations z tego mempoola, pakuje je razem i przesyła do łańcucha jako rzeczywistą transakcję, płacąc gas warstwy bazowej.
• Kontrakt EntryPoint. Jeden, poddany audytowi kontrakt EntryPoint jest wąskim gardłem on-chain. Wywołuje każdy smart account, by uruchomić własną logikę walidacji tego konta, a następnie wykonuje operację, jeśli walidacja przejdzie.
• Paymasters. Opcjonalny kontrakt paymaster może zgodzić się pokryć gas dla danej UserOperation, co czyni możliwymi przepływy bez gasu i płatności w tokenie.

Złożone razem, pozwala to dowolnemu kontraktowi działać jako w pełni programowalne konto, walidowane wedle własnych reguł, podczas gdy leżący u podstaw protokół Ethereum pozostaje dokładnie taki, jaki był. Standard jest opisany w EIP-4337, a własna mapa drogowa abstrakcji kont Ethereum śledzi, dokąd zmierza szersze przedsięwzięcie.

Dlaczego to ma znaczenie dla użytkowników samodzielnej pieczy

Dla kogoś, kto trzyma własne klucze, abstrakcja kont nie jest abstrakcyjnym szczegółem protokołu — zmienia to, co portfel może bezpiecznie robić:

• Multisig bez natywnego wsparcia. Smart account może żądać więcej niż jednego podpisu, więc portfel może wymagać, by każdy przelew zatwierdziły dwa niezależne urządzenia. To cegiełka, na której opiera się SSP, wyjaśniona szerzej w EVM Multisig na sposób abstrakcji kont.
• Opcje odzyskiwania. Programowalna walidacja otwiera drzwi do przepływów odzyskiwania, które nie sprowadzają się do jednej kruchej frazy seed.
• Sponsorowanie gasu. Paymasters oznaczają, że opłatę można odłączyć od nadawcy, łagodząc najgorsze tarcie przy rozpoczęciu.
• Scalanie. Kilka kroków może rozliczyć się jako jedna operacja, redukując zarówno kliknięcia, jak i ryzyko niepowodzenia w połowie drogi.

Praktyczna różnica między jednokluczową EOA a programowalnym smart account jest na tyle duża, że zasługuje na własne omówienie — zobacz EOA kontra smart account: różnice, które mają znaczenie.

Gdzie wpisuje się SSP

SSP to samodzielnie zarządzany portfel zbudowany wokół multisig 2-z-2. Jeden klucz mieszka w rozszerzeniu przeglądarki SSP Wallet; drugi w aplikacji mobilnej SSP Key. Każda transakcja jest konstruowana w rozszerzeniu i współpodpisywana na telefonie, więc żadne urządzenie samodzielnie nie może ruszyć środków.

Na łańcuchach EVM SSP dostarcza ten 2-z-2 za pomocą ERC-4337. Portfel jest smart account ERC-4337, którego logika walidacji wymaga obu kluczy, a dwa częściowe podpisy łączą się — w stylu MuSig2 nad secp256k1 — w jeden zagregowany podpis Schnorr, który kontrakt weryfikuje on-chain. Smart contracts SSP zostały poddane audytowi przez Halborn w 2025 roku. Pełny projekt jest tematem Architektura abstrakcji kont SSP.

Innymi słowy, abstrakcyjna zdolność opisana powyżej — konto, które egzekwuje własną regułę wielu podpisów — to dokładnie to, co SSP zamienia w działający portfel na Ethereum, Polygon, Base i pozostałych obsługiwanych łańcuchach EVM.

Reszta tej serii

Ta część postawiła problem i główny pomysł. Seria buduje stąd dalej:

1. Abstrakcja kont od pierwszych zasad — ten artykuł: dlaczego EOA są ograniczające i co oznacza abstrakcja kont.
2. EOA kontra smart account: różnice, które mają znaczenie — bezpośrednie porównanie dwóch modeli kont.
3. Architektura abstrakcji kont SSP — jak SSP wpina ERC-4337 w portfel 2-z-2.
4. Sponsorowanie gasu i paymasters wyjaśnione — jak paymasters oddzielają tego, kto płaci, od tego, kto wysyła.
5. Abstrakcja kont na łańcuchach innych niż Ethereum — jak ten sam pomysł podróżuje poza Ethereum.

Zacznij od wyjaśnienia ERC-4337, jeśli chcesz standardu w izolacji, a potem wróć tutaj po szerszy obraz. Od tego momentu konto przestaje być ograniczeniem i zaczyna być czymś, wokół czego możesz programować.