EIP-8141 w ekosystemie Ethereum wydaje się wyznaczać nowy kierunek, ponieważ współzałożyciel Ethereum Vitalik Buterin promuje tę propozycję jako sposób na poprawę wydajności dzięki skalowalnym transakcjom w sieci.

W swojej istocie propozycja oddziela wymagania związane z zatwierdzaniem transakcji od faktycznych procesów, które transakcja wykonuje. Buterin uważa, że takie podejście mogłoby pozwolić Ethereum na wydajniejsze przetwarzanie typowych transakcji bez uszczerbku dla elastyczności. Opisał ją jako jedną ze strategii poprawy skalowalności Ethereum przy zachowaniu decentralizacji. To przedsięwzięcie kontynuuje dłuższą linię prac protokołowych: ścieżka aktualizacji Ethereum przeszła już etapy takie jak przejście na proof-of-stake w 2022 roku (Merge) oraz kolejne hard forkи „Dencun” i „Pectra”, przy czym skalowalność i tańsze transakcje pozostają stałymi priorytetami w mapie drogowej rozwoju sieci.

W poście na X z 5 września 2026 roku Buterin napisał:

One positive consequence of all the recent detailed thinking about transaction formats – not just 8141, also "future of state" discussions eg. UTXOs, PBT, keyed nonces, and also recursive STARK mempool – is that we have a much more explicit understanding of how transactions have…

— vitalik.eth (@VitalikButerin) September 5, 2026 (https://x.com/VitalikButerin/status/2096378061377900881)

EIP-8141 oddziela zależności transakcji od akcji

Buterin dzieli proces wykonania transakcji na dwa podstawowe komponenty: zależności i akcje.

Zależności to wymagania, które muszą zostać spełnione, aby transakcja została uznana za ważną. Obejmują one podpisywanie transakcji, dowodzenie za pomocą drzewa Merkle, użycie ZK-SNARK lub STARK oraz inne weryfikacje.

Akcje to operacje wykonywane po sprawdzeniu wszystkich warunków wstępnych. Obejmują one wysyłanie ETH, wywoływanie smart kontraktów oraz modyfikowanie informacji w blockchainie.

W ramach metody EIP-8141 niektóre kontrole zależności mogłyby być wykonywane równolegle, zamiast aby każdy klient przechodził przez każdą kontrolę sekwencyjnie. Inne kontrole zależności mogłyby być nawet przeprowadzane, gdy transakcja czeka w mempoolu, zanim zostanie uwzględniona w bloku.

Zależności stanu pozostają bardziej złożone, ponieważ wcześniejsze transakcje mogą zmieniać salda i inne dane blockchaina. Mempoole mogłyby jednak obsługiwać takie kontrole zależności skuteczniej, gdyby transakcje precyzowały, jakiego stanu wymagają.

Buterin oszacował, że ponad 90% transakcji w sieci Ethereum nie potrzebuje pełnej elastyczności wykonania. Zaznaczył, że ta liczba jest jego własnym szacunkiem, a nie zmierzoną metryką sieci.

Projekt Frame Transaction

EIP-8141 wprowadza nowy typ transakcji o nazwie Frame Transaction. Projekt struktury oddziela wywołania kontraktów dotyczące autoryzacji, płatności opłat i operacji użytkownika.

Taka konstrukcja pozwoliłaby, aby kod konta autoryzował transakcję i opłacał opłaty, zamiast polegać na tradycyjnym mechanizmie podpisu. Potencjalne funkcje umożliwione przez tę strukturę obejmują sponsorowanie opłat, płatności opłat w tokenach, rotację kluczy i transakcje pakietowe. Te możliwości nawiązują do celów od dawna kojarzonych z abstrakcją konta — tematu, który Ethereum rozwijało wcześniej w ramach odrębnych inicjatyw, takich jak EIP-4337, wprowadzający mempool dla „UserOperations” bez zmian w protokole rdzenia; EIP-8141 działa natomiast bezpośrednio na poziomie formatu transakcji.

Weryfikacja byłaby pierwszym krokiem, określającym, czy transakcja jest uwierzytelniona. Następnie pozostałe ramki mogłyby zająć się płatnością opłaty i wykonaniem określonych akcji.

Proponowany format jest stosunkowo prosty i obejmuje wywołania kontraktów, flagi, informację o pochodzeniu oraz nonce. Ten sam format mogłyby przyjąć także inne sieci zbudowane w oparciu o model EVM.

Otwarte pytania pozostają

EIP-8141 wciąż znajduje się na etapie szkicu jako wniosek Core, co oznacza, że każdy aspekt jego technologii może ulec zmianie w trakcie prac rozwojowych. Wnioski Ethereum Improvement Proposals na etapie szkicu muszą przejść przegląd deweloperów rdzenia Ethereum i zostać zaplanowane w przyszłej aktualizacji sieci przed aktywacją — proces, który historycznie trwa od miesięcy do lat i może skutkować rewizją lub całkowitym porzuceniem propozycji. Obecna architektura obejmuje wejście do mempoolu, wykonanie ramek, potwierdzenia (receipts), podpisy, gaz oraz propagację transakcji. Deweloperzy pracują nad kwestiami denial-of-service, zastępowania transakcji, modyfikacji portfeli, konstrukcji bloków oraz RPC.

Inną otwartą kwestią jest maksymalna liczba Frame Transactions, które mogą zostać przyjęte od jednego nadawcy. Pojawiły się wątpliwości dotyczące potencjalnych konsekwencji tego limitu dla użytkowników, którzy muszą wykonać wiele transakcji w jednym bloku.

Te kwestie pokazują, że EIP-8141 wciąż stoi przed przeszkodami technicznymi, które musi pokonać, zanim stanie się częścią protokołu Ethereum.

Z perspektywy Buterina propozycja łączy abstrakcję konta z przyszłymi planami skalowalności Ethereum. EIP-8141 nie zastępuje kont Ethereum — sprawia natomiast, że szablony transakcji stają się przewidywalne. Jeśli prace rozwojowe będą kontynuowane, propozycja może odegrać integralną rolę w strategii Ethereum dotyczącej skalowania, abstrakcji konta i poprawy wydajności transakcji.