Abstrakcja kont poza Ethereum

Abstrakcję kont często przedstawia się jako historię Ethereum — sposób na przekształcenie portfela z jednym kluczem w programowalny smart account za pomocą ERC-4337. Ale ten pomysł nie kończy się na Ethereum L1. Rozprzestrzenia się dwiema bardzo różnymi drogami: na zewnątrz, na łańcuchy EVM, które dzielą model wykonawczy Ethereum, oraz natywnie, do łańcuchów zaprojektowanych od pierwszego dnia z abstrakcją kont wbudowaną w protokół. Ten artykuł mapuje ten szerszy krajobraz, wyjaśnia, czym natywna abstrakcja kont różni się od standardu ERC-4337 nałożonego na Ethereum, i szczególnie uważnie wytycza jedną granicę: gdzie kończy się ogólny ekosystem, a gdzie zaczyna się to, co SSP faktycznie obsługuje.

To ostatni artykuł naszej serii o abstrakcji kont. Jeśli podstawowe pojęcia są dla Ciebie nowe, zacznij od Abstrakcja kont od pierwszych zasad, a następnie porównaj oba modele kont w EOA kontra smart account: różnice, które mają znaczenie. Tutaj zakładamy, że z grubsza wiesz, czym jest smart account, i poszerzamy spojrzenie na resztę świata krypto.

Ten sam standard, wszędzie tam, gdzie działa EVM

Pierwszy sposób rozprzestrzeniania się abstrakcji kont jest najprostszy: podróżuje ona razem z EVM. ERC-4337 nie jest zmianą protokołu bazowego. Jest standardem na poziomie kontraktów, zbudowanym na kontrakcie EntryPoint, obiektach UserOperation, bundlerach i opcjonalnych paymasterach — nic z tego nie wymaga zmian konsensusu. Ta decyzja projektowa ma potężną konsekwencję. Każdy łańcuch, który uruchamia Ethereum Virtual Machine, może hostować ten sam EntryPoint, tę samą infrastrukturę bundlerów i te same kontrakty smart account.

Właśnie dlatego główne L2 i sidechainy EVM obsługują ERC-4337 w taki sam sposób jak Ethereum:

• Polygon uruchamia EVM, więc ten sam kontrakt smart account i ten sam EntryPoint wdrażają się bez modyfikacji.
• Base to L2 EVM, na którym abstrakcja kont ERC-4337 działa tak samo jak na L1.
• BNB Smart Chain jest kompatybilny z EVM i hostuje ten sam standard.
• Avalanche C-Chain uruchamia EVM i obsługuje tę samą abstrakcję kont na poziomie kontraktów.

Ponieważ standard jest przenośny, logika smart account portfela napisana dla Ethereum przenosi się na te łańcuchy praktycznie bez zmian. To właśnie ta przenośność pozwala SSP uruchamiać swój projekt na każdym obsługiwanym łańcuchu EVM — ten sam kontrakt 2-z-2 zachowuje się identycznie, niezależnie od tego, czy zostanie wdrożony na Ethereum, Polygon, Base, BNB Smart Chain czy Avalanche. Praktyczne, łańcuch po łańcuchu, spojrzenie na korzystanie z SSP w tych sieciach znajdziesz w Korzystanie z SSP na Polygon, Base i innych łańcuchach EVM.

Natywna abstrakcja kont: gdy jest protokołem, a nie warstwą

Drugi sposób rozprzestrzeniania się abstrakcji kont jest zasadniczo inny. Niektóre łańcuchy nie czekały na opcjonalny standard — wbudowały abstrakcję kont bezpośrednio w protokół, tak że nie istnieje żadne rozróżnienie między „EOA a smart account". Każde konto jest domyślnie smart accountem.

Starknet: każde konto jest kontraktem

Starknet ma abstrakcję kont od pierwszego dnia. W Starknecie nie ma kont z zewnętrzną własnością w sensie Ethereum; każde konto jest kontem kontraktowym, napisanym w języku Cairo. Ponieważ zachowanie konta jest definiowane przez kod kontraktu na poziomie protokołu, schematy podpisów, reguły walidacji, multisig i logika opłat są właściwościami samego konta, a nie funkcjami doczepionymi później.

Kontrast z Ethereum jest pouczający. W Ethereum kontem domyślnym jest EOA z jednym zaszytym na stałe sprawdzeniem ECDSA, a ERC-4337 istnieje po to, by nałożyć programowalne konta na wierzch bez hard forka. W Starknecie nie ma nic do nałożenia — programowalne konto jest podstawą. Nie ma osobnego standardu EntryPoint do przyjęcia, ponieważ abstrakcja kont nie jest opcjonalna. Dokumentacja Starknet pod adresem docs.starknet.io szczegółowo opisuje ten model konta.

zkSync Era: natywna AA z wbudowanymi paymasterami

zkSync Era przyjmuje podobne, natywne dla protokołu podejście. Abstrakcja kont jest częścią protokołu, a nie dodatkiem, a system zawiera wbudowane wsparcie dla paymasterów na poziomie protokołu. W Ethereum paymaster jest kontraktem zdefiniowanym przez standard ERC-4337 i kierowanym przez EntryPoint; w zkSync Era funkcjonalność paymastera jest pierwszorzędną cechą samego łańcucha, więc sponsorowanie opłat lub płacenie gas w innym token jest częścią tego, jak sieć jest zaprojektowana, by działać. Dokumentacja zkSync obejmuje jego natywną abstrakcję kont i model paymastera.

Natywna AA kontra ERC-4337: kluczowa różnica

Warto wprost wyrazić to rozróżnienie, ponieważ jest ono konceptualnym sednem tego artykułu:

• ERC-4337 to opcjonalny standard nałożony na niezmieniony protokół. Warstwa bazowa Ethereum nadal natywnie rozumie tylko EOA i ich jeden podpis ECDSA. Smart accounty istnieją, ponieważ deweloperzy uzgodnili wspólny zestaw komponentów on-chain i off-chain — EntryPoint, alternatywny mempool, bundlery — które symulują abstrakcję kont na poziomie protokołu bez zmiany konsensusu. Jest to genialne właśnie dlatego, że nie wymagało żadnego hard forka, i z tego samego powodu jest przenośne na każdy łańcuch EVM.
• Natywna abstrakcja kont jest wbudowana w protokół. W Starknecie i zkSync Era sam łańcuch traktuje każde konto jako programowalne. Nie ma opcji, nie ma osobnego standardu do przyjęcia ani rozróżnienia między „zwykłym" a inteligentnym kontem — smart account jest kontem.

Oba podejścia dostarczają użytkownikowi końcowemu tych samych korzyści: wielu sygnatariuszy, niestandardową walidację, logikę odzyskiwania i elastyczny gas. Po prostu docierają z przeciwnych kierunków — jedno jako starannie zaprojektowana warstwa, drugie jako fundamentalna decyzja protokołu. Jeśli chcesz formalnej specyfikacji podejścia warstwowego, EIP-4337 jest kanonicznym źródłem.

Gdzie pasuje SSP — a gdzie nie

To jest granica, co do której trzeba być precyzyjnym. SSP to portfel samodzielnej kontroli zbudowany wokół multisig 2-z-2: jeden klucz w rozszerzeniu przeglądarki SSP Wallet, drugi w aplikacji mobilnej SSP Key, przy czym żadne urządzenie samodzielnie nie może przesyłać środków. Na łańcuchach EVM SSP implementuje to jako smart account ERC-4337, którego logika walidacji weryfikuje pojedynczy zagregowany podpis Schnorr zbudowany z obu kluczy. Smart contracts SSP zostały zaudytowane przez Halborn w 2025 roku.

Ponieważ ERC-4337 jest przenośny w całym EVM, podejście SSP przenosi się na obsługiwane przez nie łańcuchy EVM: Ethereum, Polygon, Base, BNB Smart Chain i Avalanche C-Chain. Ten sam kontrakt smart account 2-z-2 działa na wszystkich z nich.

Starknet i zkSync Era pojawiają się w tym artykule jako część szerszego ekosystemu — przykłady łańcuchów, w których abstrakcja kont jest natywna dla protokołu. Nie są częścią zestawu łańcuchów obsługiwanych przez SSP. SSP przynosi abstrakcję kont ERC-4337 na wymienione powyżej łańcuchy EVM; nie działa na Starknecie, zkSync Era ani innych łańcuchach spoza EVM. Gdy czytasz o natywnej AA gdzie indziej w świecie krypto, traktuj to jako kontekst tego, jak rozpowszechniony stał się model smart account, a nie jako twierdzenie o tym, gdzie działa SSP.

Dlaczego to ma znaczenie

Gdy spojrzeć z dystansu, wzorzec jest jasny: doświadczenie smart account staje się standardem w dużej części świata krypto, a nie niszową funkcją dla zaawansowanych użytkowników.

• Na EVM ERC-4337 przynosi programowalne konta na Ethereum i na każdy kompatybilny łańcuch bez hard forka, co pozwala portfelowi takiemu jak SSP oferować na Polygon, Base, BNB Smart Chain i Avalanche to samo bezpieczeństwo 2-z-2, które oferuje na Ethereum.
• Na łańcuchach natywnie abstrahowanych pytanie „czy to EOA, czy smart account?" po prostu się nie pojawia, ponieważ istnieje tylko jeden rodzaj konta i jest ono programowalne.

Dla użytkownika samodzielnej kontroli wniosek jest taki, że sztywny model z jednym kluczem nie jest już jedyną opcją i coraz częściej nie jest opcją domyślną. Niezależnie od tego, czy abstrakcja kont przychodzi jako warstwowy standard, czy jako natywna funkcja protokołu, cel jest ten sam: konta, które możesz programować, z regułami bezpieczeństwa — takimi jak dwuurządzeniowy multisig SSP — których pojedynczy klucz prywatny nigdy nie zdołałby wyegzekwować samodzielnie. Aby przypomnieć sobie, jak ten model wypada w porównaniu z oryginalnym kontem Ethereum, zobacz EOA kontra smart account: różnice, które mają znaczenie, a dla samego standardu Czym jest abstrakcja kont (ERC-4337)?.