EOA a smart account: różnice, które mają znaczenie
Jeśli korzystałeś z portfela kryptowalut, korzystałeś z konta. Ale nie wszystkie konta na Ethereum są takie same. Istnieją dwa zasadniczo różne rodzaje, a różnica kształtuje niemal wszystko w zachowaniu twojego portfela: jak podpisujesz, kto może autoryzować płatność, jak odzyskujesz dostęp, kto płaci opłatę i w jakim tokenie.
Ten artykuł omawia po kolei dwa rodzaje kont — externally owned account (EOA) oraz smart account — i porównuje je według osi, które użytkownik samodzielnego przechowywania faktycznie odczuwa na co dzień. To drugi artykuł naszej serii o account abstraction; jeśli nie czytałeś Account abstraction od pierwszych zasad, to dobry punkt wyjścia. Tutaj skupiamy się konkretnie na rozróżnieniu między EOA a smart account.
Czym jest EOA?
Externally owned account to pierwotne konto Ethereum. Definiuje je dokładnie jedna para kluczy secp256k1: klucz prywatny i wyprowadzony z niego klucz publiczny. Adres, który widzisz — ciąg 0x... — jest wyprowadzony z tego klucza publicznego. Kto posiada klucz prywatny, ten kontroluje konto, i kropka.
Ten jeden klucz wykonuje całą pracę. Podpisuje każdą transakcję podpisem ECDSA. Do konta nie jest dołączony żaden kod, żadne reguły, żadne warunki. Jedyne pytanie sieci, gdy nadchodzi transakcja, brzmi: „Czy ten podpis jest prawidłowy dla tego adresu?”. Jeśli tak, transakcja zostaje wykonana.
Większość portfeli w postaci rozszerzenia przeglądarki, z którymi się zetknąłeś — model jednoklucza w stylu MetaMask — tworzy EOA. Jedna fraza seed wyprowadza klucz, klucz kontroluje konto, a ochrona tej frazy seed to cały model bezpieczeństwa. Jest prosty, dobrze zrozumiany i działa od dekady. Jest też sztywny: jeden klucz, jeden podpisujący, jeden schemat podpisu, a jeśli ten klucz wycieknie, konto przepada.
Czym jest smart account?
Smart account to konto kontraktowe: konto, którego zachowanie definiuje wdrożony kod, a nie pojedynczy klucz. Zamiast „czy ten jeden podpis ECDSA jest prawidłowy”, konto uruchamia własną logikę walidacji, aby zdecydować, czy zaakceptować operację. Ta logika jest programowalna.
Ponieważ reguły żyją w kodzie, smart account może wymagać dwóch podpisów zamiast jednego, akceptować schematy podpisu inne niż zwykły ECDSA, narzucać limity wydatków lub definiować ścieżkę odzyskiwania — cokolwiek określa jego kontrakt. Portfele oparte na inteligentnych kontraktach w stylu Safe to dobrze znany przykład tego modelu. Na Ethereum i innych łańcuchach EVM standardem, który pozwala takim kontom zachowywać się jak pełnoprawne konta bez zmiany protokołu, jest ERC-4337.
Kontrola: jeden klucz a reguły niestandardowe
To główna różnica. EOA ma w protokole wpisaną dokładnie jedną regułę: jeden prawidłowy podpis ECDSA jednego klucza autoryzuje wszystko. Nie ma sposobu, by dodać drugiego wymaganego zatwierdzającego ani powiedzieć „kwoty powyżej tego progu wymagają dodatkowego potwierdzenia”. Klucz jest kontem.
Smart account decyduje sam za siebie. Może wymagać kworum multisig, ograniczać określone działania lub nakładać klucze sesyjne. SSP wykorzystuje to, aby dostarczyć 2-of-2 multisig: jeden klucz znajduje się w rozszerzeniu przeglądarki SSP Wallet, drugi w aplikacji mobilnej SSP Key, a logika walidacji konta wymaga zatwierdzenia przez oba, zanim zaakceptuje jakąkolwiek transakcję. Samo wyciekłe rozszerzenie przeglądarki nie może przenieść środków, ponieważ kontrakt po prostu nie zaakceptuje autoryzacji jednoklucza.
Odzyskiwanie: co się dzieje, gdy klucz zostaje utracony
Przy EOA klucz jest kontem. Zgub frazę seed, a konto jest nie do odzyskania; pozwól jej wyciec, a atakujący ma pełną kontrolę. Nie ma wbudowanego środka zaradczego, bo nie ma logiki, do której można by się odwołać — liczy się tylko ten jeden klucz.
Smart account może zdefiniować odzyskiwanie jako część swoich reguł. Ponieważ walidacja jest programowalna, kontrakt może określić alternatywne ścieżki autoryzacji, wyznaczone strony odzyskiwania lub rotację kluczy z opóźnieniem czasowym. Konkretny model SSP to 2-of-2: utrata dostępu do któregokolwiek z urządzeń nie oddaje twoich środków atakującemu, ponieważ oba podpisy są zawsze wymagane. Praktyczny efekt jest taki, że żadne pojedyncze urządzenie nie stanowi pojedynczego punktu awarii.
Kto płaci za gas i w jakim tokenie
EOA płaci za własne transakcje, i płaci w natywnej monecie łańcucha. Aby przenieść token ERC-20 na Ethereum, EOA wciąż potrzebuje ETH na pokrycie gas. Jeśli twoje konto ma tokeny, ale nie ma ETH, utkniesz — częste i frustrujące doświadczenie początkujących.
Smart account może zerwać to powiązanie. W ramach ERC-4337 komponent zwany paymaster może sponsorować gas dla operacji albo przyjąć płatność w tokenie innym niż natywna moneta. Opłatę może pokryć strona trzecia albo można ją zapłacić tym samym tokenem, który już przenosisz. Omawiamy to szczegółowo w artykule Sponsorowanie gas i paymastery wyjaśnione; chodzi tu o to, że „kto płaci i czym” przestaje być ustalone na stałe.
Grupowanie wielu działań
Przy EOA każda transakcja to osobna, indywidualnie podpisana operacja. Klasyczny wzorzec ERC-20 — zatwierdzenie, by kontrakt wydał twoje tokeny, a następnie wywołanie kontraktu — to dwie transakcje, dwa podpisy, dwie płatności gas, po kolei.
Smart account może zgrupować kilka działań w jedną operację, która albo w pełni się powiedzie, albo w pełni zostanie wycofana. Zatwierdź i wymień staje się jednym krokiem. Po części to wygoda, a po części bezpieczeństwo: nie istnieje stan w połowie ukończony, w którym udzieliłeś zatwierdzenia, ale kolejne działanie nigdy nie nastąpiło.
Schematy podpisu
EOA weryfikuje jedną rzecz: podpis ECDSA na secp256k1. To jedyny schemat, który protokół sprawdza dla externally owned accounts, i nie można go zmienić.
Smart account weryfikuje to, co jego kod został napisany, by weryfikować. Może sprawdzać wiele podpisów, egzotyczne krzywe lub podpisy zagregowane. Konta EVM SSP weryfikują zagregowany podpis Schnorr: dwa częściowe podpisy z rozszerzenia przeglądarki i aplikacji mobilnej łączą się — w stylu MuSig2 na secp256k1 — w jeden podpis on-chain, który waliduje kontrakt. Łańcuch widzi jeden podpis; model bezpieczeństwa za nim to dwóch niezależnych zatwierdzających. To coś, czego EOA z założenia strukturalnego nie potrafi.
Wdrożenie i adresy
EOA istnieje w chwili, gdy istnieje klucz. Wygeneruj parę kluczy offline, a odpowiadający adres jest już prawidłowy; nic nie kosztuje i nie dotyka żadnego kontraktu. Konto po prostu jest.
Smart account jest kontraktem, więc musi zostać wdrożone on-chain, zanim będzie mogło nosić zachowanie zdefiniowane w kodzie. W praktyce portfele ERC-4337 używają deterministycznego, kontrfaktycznego adresu: adres jest obliczany z góry na podstawie parametrów konta, dzięki czemu może przyjmować środki, zanim kontrakt zostanie faktycznie wdrożony, a wdrożenie następuje przy pierwszym użyciu. Możesz udostępnić swój adres i otrzymać płatność, zanim jakakolwiek transakcja wdrożeniowa zostanie sfinalizowana.
Koszt: uczciwy kompromis
Programowalność nie jest darmowa. Ponieważ smart account uruchamia logikę walidacji w kontrakcie, jego operacje kosztują nieco więcej gas niż zwykły przelew z EOA, który należy do mniej więcej najtańszych, jakie potrafią być transakcje Ethereum. Pierwsze wdrożenie konta również wiąże się z jednorazowym kosztem.
Dla większości użytkowników samodzielnego przechowywania to rozsądna cena za bezpieczeństwo dwóch kluczy, opcje odzyskiwania, grupowanie i elastyczny gas. Ale to realna różnica i warto nazwać ją wprost, zamiast ją pomijać.
Czego używa SSP i kiedy każdy model ma sens
Mówiąc wprost: SSP używa smart account poprzez ERC-4337, aby dostarczyć swój 2-of-2 multisig na łańcuchach EVM — Ethereum, Polygon, Base, BNB Smart Chain i Avalanche. Kontrakt wymaga zagregowanego podpisu Schnorr zbudowanego z obu twoich urządzeń, a implementacja EVM SSP została poddana audytowi przez Halborn w 2025 roku. Aby zobaczyć, jak elementy do siebie pasują, przeczytaj architekturę account abstraction w SSP, a po szczegóły dotyczące konkretnego łańcucha zajrzyj do Ethereum w SSP.
Kiedy więc każdy model ma sens? EOA to najprostsze możliwe konto: najtańszy gas, natychmiastowe istnienie, brak wdrożenia. Dla konfiguracji jednego użytkownika z jednym kluczem, gdzie priorytetem jest prostota, jest w pełni przydatne. Smart account ma sens, gdy chcesz właściwości, których pojedynczy klucz nie może ci dać — wielu wymaganych zatwierdzających, logiki odzyskiwania, grupowania, sponsorowanego lub denominowanego w tokenie gas. Kompromisem jest nieco wyższy gas oraz samo pojęcie wdrożenia.
Dla portfela samodzielnego przechowywania, którego całą przesłanką jest to, że żaden pojedynczy klucz nie powinien być pojedynczym punktem awarii, smart account jest naturalnym wyborem. Dlatego SSP jest na nim zbudowany. Aby zgłębić sam model kont Ethereum, dokumentacja kont Ethereum jest miarodajnym źródłem, a specyfikacja ERC-4337 to standard, który sprawia, że smart accounts są dziś praktyczne.
