Dlaczego EOA są przestarzałe: jak naprawdę działa smart account

Według danych BundleBear z kwietnia 2026 r. wykonano ponad 1,07 miliarda operacji UserOperation ERC-4337, a 56,7 miliona smart accountów przeprowadziło co najmniej jedną transakcję w sieci Ethereum i największych sieciach L2. To już nie nisza. Konto Externally Owned Account, wprowadzone wraz z Ethereum w 2015 r., oparte wyłącznie na jednym kluczu i krzywej secp256k1, jest omijane na dużą skalę. Dane on-chain potwierdzają przy tym mniej nagłośniony fakt dotyczący protokołu: samo konto jest już programowalne.

To pierwsza część pięcioczęściowej serii o smart accountach. Jej cel jest wąski, ale fundamentalny: wyjaśnić, czym właściwie jest EOA, czym jest smart account i dlaczego wybór między smart accountem a EOA nie sprowadza się już do preferencji dotyczących UX, lecz dotyczy struktury, która egzekwuje zasady samodzielnego przechowywania środków.

Czym właściwie jest EOA z punktu widzenia protokołu

Yellow Paper Ethereum definiuje dwa typy kont: Externally Owned Accounts i Contract Accounts. Jedyną różnicą między nimi na poziomie stanu jest pole codeHash. W przypadku EOA codeHash jest hashem pustego ciągu znaków. W przypadku konta kontraktowego wskazuje na wykonywalny kod bajtowy EVM. Na poziomie protokołu to cała różnica.

EOA nie jest więc „portfelem” w żadnym istotnym znaczeniu tego słowa. To adres utworzony z ostatnich 20 bajtów keccak256(public key), powiązany na stałe z parą kluczy opartą na krzywej secp256k1. MetaMask, Ledger i Zelcore to interfejsy użytkownika, które przechowują klucz. Nie są kontem. Jeśli nie znasz jeszcze tego mechanizmu, nasz wstęp do kluczy publicznych i prywatnych oraz sposobu wyznaczania adresu wyjaśnia go od początku do końca.

Do czasu wdrożenia ERC-4337 w 2023 r. każda transakcja w sieci Ethereum musiała pochodzić z EOA, a protokół egzekwował dokładnie jedną regułę walidacji: poprawny podpis secp256k1 złożony dla hasha transakcji. Konto musi mieć saldo, a użytkownik składa jeden podpis ECDSA dla każdej transakcji i płaci za gaz w ETH z tego samego konta. Tyle może EOA. Nic więcej.

Ograniczenia strukturalne istotne dla użytkowników

To nie są drobne niedogodności związane z UX. To strukturalne przyczyny większości strat związanych z samodzielnym przechowywaniem środków, które nadal obserwujemy w 2026 r.

• Jeden punkt awarii. Jeden klucz prywatny kontroluje wszystko. Utrata klucza oznacza utratę konta. Jego ujawnienie oznacza nieodwracalną utratę środków. Protokół nie zapewnia mechanizmu odzyskiwania. Właśnie dlatego pojedyncza fraza seed jest głównym punktem awarii przy samodzielnym przechowywaniu środków.
• Jedna krzywa. secp256k1 jest zakodowana na stałe. Nie można użyć klucza dostępu (P-256), klucza Ed25519, BLS ani algorytmu postkwantowego.
• Brak natywnej obsługi multisig. Każdy mechanizm „multisig” w sieci Ethereum, od pierwszego Gnosis Multisig po Safe, jest kontraktem wywoływanym przez EOA. Samo EOA nigdy nie może wymagać dwóch podpisów.
• Brak łączenia operacji. EOA wykonuje jedną czynność na transakcję. Zatwierdzenie tokena, a następnie jego wymiana to dwie podpisane transakcje, dwa potwierdzenia i dwie opłaty za gaz.
• Brak zasad wydawania środków. Protokół nie rozumie reguł takich jak „ten klucz może wydać maksymalnie 500 USD dziennie” ani „ten klucz może wywoływać tylko Uniswap”.
• Opłatę za gaz musi uiścić w ETH to samo konto, które wykonuje daną czynność. Protokół nie zapewnia natywnego sponsorowania opłat ani płatności w USDC.

To model, w którym przez dekadę musiał działać każdy użytkownik Ethereum.

Czym właściwie jest smart account

W dosłownym rozumieniu protokołu smart account to konto kontraktowe: adres, którego codeHash wskazuje na kod bajtowy. Ten kod określa zasady, według których konto akceptuje działania.

W przypadku EOA reguła walidacji to jeden niezmienny test secp256k1. W smart accouncie obowiązuje reguła określona w kontrakcie. Może to być multisig 2 z 3, podpis kluczem dostępu weryfikowany na krzywej secp256r1, klucz poświadczony przez portfel sprzętowy, blokada czasowa, dzienny limit, dozwolony adres wywołania albo dowolne połączenie tych rozwiązań. Konta smart contract weryfikują podpisy zgodnie ze standardem EIP-1271, a nie za pomocą stałego testu secp256k1 na poziomie protokołu. Dzięki temu możliwe są alternatywne schematy podpisu.

Ponieważ reguły zapisano w kodzie, można je aktualizować, łączyć i unieważniać. Smart accounty istnieją w sieci Ethereum od 2018 r. (kanonicznym przykładem jest Safe). Brakowało sposobu, by uczynić je domyślnymi i wysyłać transakcje bez konieczności wcześniejszego opłacenia gazu przez EOA. Tę lukę wypełniły ERC-4337 i EIP-7702.

Jak do tego doszło: krótka historia abstrakcji kont

Pomysł połączenia EOA i kontraktów jest tak stary jak samo Ethereum. EIP-86 autorstwa Vitalika, opracowany w 2016 r., był pierwszą szczegółową propozycją. Droga od niego do wdrożonych dziś standardów wymagała pięciu prób.

• EIP-2938 (wrzesień 2020 r.) proponował abstrakcję kont na poziomie protokołu. Porzucono go jako zbyt inwazyjny projekt, gdy Ethereum było w trakcie przechodzenia na proof of stake.
• EIP-3074 (październik 2020 r.) wprowadzał kody operacji AUTH i AUTHCALL, które pozwalały EOA delegować uprawnienia kontraktowi invoker. Wycofano go z powodu obaw o bezpieczeństwo i zastąpiono innym rozwiązaniem.
• ERC-4337 uruchomiono w sieci głównej Ethereum 1 marca 2023 r. Działa wyłącznie na warstwie aplikacji, bez hard forka. Kieruje pseudotransakcje zwane UserOperations przez oddzielną pulę pamięci, usługę Bundler i pojedynczy kontrakt EntryPoint.
• EIP-7702 wdrożono wraz z aktualizacją Pectra 7 maja 2025 r. Wprowadza typ transakcji 0x04, w którym EOA podpisuje krotkę autoryzacji (chain_id, address, nonce, y_parity, r, s). Wskazuje ona konto jako korzystające z delegowanego kodu kontraktu za pomocą wskaźnika 0xef0100 || address. EOA tymczasowo działa wtedy jak smart account, bez przenoszenia środków.
• ERC-6900 standaryzuje modułową architekturę wtyczek, dzięki której smart accounty łączą moduły walidacji, wykonywania i hooków.

Wniosek: abstrakcja kont nie jest już eksperymentem. To wdrożony, warstwowy standard z przejrzystą ścieżką ERC-4337 dla nowych smart accountów oraz ścieżką EIP-7702, która pozwala każdemu istniejącemu EOA z niej skorzystać.

Pięć możliwości, które daje smart account

Jeśli EOA oznacza „jeden klucz, jeden podpis, jedna transakcja”, smart account oferuje ściśle szerszy zakres możliwości.

• Programowalna walidacja. Dowolny schemat podpisu (klucz dostępu, P-256, sprzętowy moduł HSM), dowolne kworum (2 z 3, 3 z 5) i dowolny warunek (wysokość bloku, cena z wyroczni). Konto samo określa, co oznacza „autoryzowane”.
• Atomowe łączenie operacji. Zatwierdź, wymień i zdeponuj środki w ramach jednego podpisanego działania. Wykonane zostaną wszystkie te czynności albo żadna. Dzięki temu znikają obejścia, które użytkownicy musieli stosować ręcznie, by poradzić sobie z zatwierdzaniem tokenów i mechanizmem multisig w Zelcore.
• Abstrakcja opłat za gaz dzięki paymasterom. Kontrakt strony trzeciej płaci za gaz w imieniu użytkownika albo użytkownik płaci w USDC, USDT lub dowolnym tokenie ERC-20 akceptowanym przez paymastera. Aby lepiej zrozumieć, jak działają razem gaz, zatwierdzanie transakcji i mechanizmy DeFi, najpierw zapoznaj się z artykułem o podstawach DeFi.
• Klucze sesyjne. Klucze do podpisywania o ograniczonym zakresie, czasie ważności i zastosowaniu w konkretnej aplikacji. „Ten klucz może wydać maksymalnie 100 USDC na Uniswap przez następne 24 godziny”. Skutki przejęcia klucza sesyjnego ograniczają zasady, a nie wartość środków na koncie.
• Odzyskiwanie dostępu. Odzyskiwanie społeczne, za pomocą portfela sprzętowego lub po upływie blokady czasowej. Konto można odzyskać bez pierwotnego klucza do podpisywania. Dzięki temu fraza seed przestaje być jedynym punktem awarii.

Dlaczego to ma teraz kluczowe znaczenie dla samodzielnego przechowywania

Dziś skala adopcji nie podlega już dyskusji. W pierwszym tygodniu po Pectra EIP-7702 zebrał ponad 11 000 autoryzacji, a wkrótce potem liczba portfeli przekroczyła 25 000. Na czele znalazły się OKX i MetaMask. Bieżące sumy BundleBear (1.07B UserOps, 56.7M smart accounts) dopełniają obrazu.

Zmienia się przede wszystkim model zagrożeń. W przypadku EOA użytkownik ma „na zawsze chronić frazę seed, nigdy nie podpisać złośliwej transakcji, nigdy nie paść ofiarą phishingu i nigdy nie użyć ponownie niewłaściwego urządzenia”. To zadanie, z którym ludzie, jak wiadomo, sobie nie radzą. W przypadku smart account użytkownik ma „raz skonfigurować kworum odzyskiwania i zasady wydatków”. To zadanie, które może egzekwować kod.

Smart account nie zastępuje portfela sprzętowego. Pozwala mu robić więcej, a w praktyce ogranicza rolę, jaką portfel sprzętowy nadal pełni w smart account, do najważniejszego zastosowania: podpisywania rzadkich operacji głównych o dużej wartości, podczas gdy codziennymi działaniami zajmują się klucze sesyjne.

Co dalej w tej serii

To było wprowadzenie. W kolejnych częściach omówimy praktyczne aspekty.

• Część 2 przedstawia stos ERC-4337: UserOperations, Bundlers, EntryPoint, Paymasters oraz miejsca, w których każdy z tych elementów może zawieść.
• Część 3 szczegółowo omawia delegowanie EIP-7702: krotkę autoryzacji, wskaźnik 0xef0100 i kwestie bezpieczeństwa związane ze wskazaniem kodu należącego do kogoś innego jako kodu dla własnego EOA.
• Część 4 porównuje główne implementacje smart account (Coinbase Smart Wallet, Safe, Argent, Ambire) i wyjaśnia, jakie ustawienia domyślne ma każda z nich.
• Część 5 podsumowuje praktyczne kwestie: pokazuje, jak skonfigurować odzyskiwanie dostępu, klucze sesyjne i zasady wydatków na prawdziwym koncie, zachowując samodzielne przechowywanie.

Jedno zdanie, które warto zapamiętać przed częścią 2: EOA to klucz z adresem, a smart account to kontrakt, który decyduje, co wolno zrobić za pomocą jego klucza.