Ethereum ma zyskać nowy prymityw transakcyjny, który może zmienić sposób, w jaki portfele, dApp-y i smart kontrakty współdziałają z siecią. EIP-8141 wprowadza tzw. "Frame Transaction" — pojedynczą transakcję, którą można podzielić na maksymalnie 64 programowalne podjednostki zwane ramkami, z których każda może wykonywać różne operacje w ramach jednego atomowego wykonania.

Propozycja, współtworzona przez Vitalika Buterina i kilku kluczowych współpracowników, została zgłoszona 29 stycznia 2026 roku. Następnie nadano jej status "Scheduled" w ramach włączenia do hard forka Hegotá w 2027 roku, co oznacza, że przeszła wstępne przeglądy proceduralne, ale nadal podlega procesowi ulepszania Ethereum, w którym zaplanowane propozycje mogą być zmieniane lub ponownie rozpatrywane przed ostatecznym włączeniem do aktualizacji sieci.

Co faktycznie robią transakcje ramkowe

Nowy typ transakcji, oznaczony jako 0x06, pozwala każdej ramce działać w jednym z trzech trybów. DEFAULT obsługuje standardowe wdrażanie transakcji. VERIFY wykonuje walidację tylko do odczytu, przydatną do sprawdzania warunków bez zmiany stanu. SENDER wykonuje się w kontekście nadawcy transakcji, umożliwiając wzorce, które wcześniej wymagały wdrażania dedykowanych portfeli smart kontraktowych.

Każda ramka ma koszt wewnętrzny 12 000 gazu plus 475 gazu za ramkę. Dla porównania, podstawowy przelew Ethereum kosztuje obecnie 21 000 gazu, więc narzut na ramkę jest stosunkowo niewielki w zestawieniu z funkcjonalnością, którą odblokowuje.

Propozycja wprowadza również kilka nowych kodów operacji. Opcode APPROVE (0xaa) obsługuje logikę autoryzacji, a zestaw opcode'ów TXPARAM, FRAME i SIG daje deweloperom precyzyjną kontrolę nad tym, jak ramki odwołują się do siebie, przekazują parametry i weryfikują podpisy.

Dlaczego to ważne: natywna abstrakcja kont bez obejść

Ekosystem od lat zmierza w stronę abstrakcji kont poprzez propozycje takie jak ERC-4337, wprowadzony w 2021 roku, który stworzył "alternatywny mempool" dla transakcji z abstrakcją kont bez zmiany samego protokołu. EIP-7702 przyjął inne podejście, pozwalając EOA tymczasowo delegować do kodu smart kontraktu; został włączony do aktualizacji Pectra, która wystartowała w 2025 roku. ERC-4337 dodaje złożoność infrastrukturalną w postaci bundlerów i paymasterów, a EIP-7702 wymaga trwałych konfiguracji delegacji.

EIP-8141 idzie trzecią drogą, wbudowując te możliwości bezpośrednio w format transakcji. Pojedyncza transakcja ramkowa może obejmować krok weryfikacji, zatwierdzenie i wykonanie — wszystko bez konieczności wdrażania przez użytkownika portfela smart kontraktowego lub polegania na infrastrukturze bundlerów stron trzecich.

Propozycja jawnie uzupełnia, a nie zastępuje EIP-7702 i ERC-4337. Deweloperzy, którzy już zbudowali na tych standardach, nie będą musieli usuwać istniejących integracji.

Sponsorowanie gazu i atomowe grupowanie

W przypadku transakcji ramkowych strona trzecia może pokryć koszty gazu w ramach tej samej struktury transakcji. dApp mógłby wprowadzać nowych użytkowników posiadających zero ETH, sponsorując ich pierwsze interakcje — bez zewnętrznych sieci przekaźnikowych czy schematów podpisów off-chain.

Atomowe grupowanie pozwala połączyć operacje approve-and-swap w jedno atomowe działanie: albo wszystko się wykona, albo nic. Eliminuje to obecne ryzyko, w którym udane zatwierdzenie, po którym następuje nieudany swap, pozostawia kontrakt uprawnionym do wydawania tokenów.

Płacenie opłat w ERC-20 to kolejny godny uwagi element. Użytkownicy mogliby płacić opłaty transakcyjne w stablecoinach lub innych tokenach zamiast w ETH, przy czym ramka obsługiwałaby logikę konwersji lub płatności w sposób wbudowany.

Użytkownicy mogą także tworzyć tymczasowe konta o konkretnym przeznaczeniu dla pojedynczych transakcji — bez wdrażania trwałych kont smart ani konfigurowania delegacji.

Implikacje postkwantowe i pozycjonowanie długoterminowe

Transakcje ramkowe tworzą naturalną strukturę dla wprowadzenia postkwantowych schematów podpisów. Ponieważ każda ramka może mieć własną logikę weryfikacji podpisu, sieć mogłaby obsługiwać algorytmy odporne na komputery kwantowe obok istniejących podpisów ECDSA bez konieczności twardego przełączenia. Praktyczna adopcja, jak w przypadku wcześniejszych dodatków protokołowych, zależeć będzie od wsparcia portfeli i narzędzi po wdrożeniu hard forka.