Badacze firmy Nethermind, dewelopera klienta Ethereum, opublikowali benchmark badający, jak duży może być budżet walidacji zdefiniowany parametrem MAX_VERIFY_GAS w EIP-8141, zanim węzły Ethereum staną się podatne na ataki typu denial-of-service (DoS) na mempool. Główny wniosek badania jest taki, że zabezpieczenie na poziomie klienta — wstrzymanie walidacji mempoolu podczas przetwarzania bloku — decyduje o tym, czy limit 300 000 gas jest wykonalny, czy konfiguracja wyczerpuje zasoby węzła pod wpływem utrzymującego się floodu atakującego.

Co budżet walidacji EIP-8141 ma ograniczać

EIP-8141 to draftowa propozycja Standards Track Core zatytułowana "Frame Transaction." Zgodnie z jej deklarowanym celem propozycja dodaje warstwę abstrakcji ramki dla walidacji transakcji, wykonania i płatności gas, umożliwiając transakcjom przenoszenie własnej logiki walidacji przed przyjęciem do mempoolu i ostatecznym włączeniem do bloku. Treść propozycji jest dostępna w repozytorium EIP Ethereum. Sam mempool to kolejka, w której węzły przechowują transakcje, które przeszły walidację i czekają na włączenie do bloku — dlatego obliczenia na etapie przyjęcia są punktem centralnym omawianego tu zagrożenia DoS.

Budżet walidacji — zdefiniowany przez parametr o nazwie MAX_VERIFY_GAS — określa, ile obliczeń węzeł musi wykonać, aby przyjąć pojedynczą transakcję ramkową. Przy 100 000 gas na transakcję obecny draftowy limit jest zbyt niski, by objąć rzeczywiste przypadki użycia: pojedyncza prywatna wyplata Groth16 wymaga 211 828 gas na walidację, a warianty podpisów SPHINCS+ wymagają nawet 276 000 gas. Limit musi zatem wzrosnąć, aby był praktyczny, ale każda korekta w górę powiększa powierzchnię ataku dostępną dla przeciwników skłonnych zalewać węzły kosztownymi, nieudanymi transakcjami.

Napięcie projektowe jest znane każdemu, kto śledził debatę o abstrakcji konta w EIP-4337: praca walidacyjna odbywająca się poza ścieżką wykonania jest tania dla atakujących, ale kosztowna dla węzłów. EIP-8141 przenosi tę pracę do budżetu wymuszanego przez protokół, co przynajmniej ogranicza koszt. Pytanie, gdzie umieścić tę granicę, wiąże się jednak z bezpośrednim kompromisem między bogactwem funkcji a odpornością mempoolu.

EIP-8141 pozostaje draftową propozycją i nie jest aktywowany w żadnej działającej sieci Ethereum. Wyniki benchmarku są wkładem badawczym do tej dyskusji projektowej, a nie opisem wdrożonej konfiguracji.

Jak benchmark mierzy ekspozycję mempoolu na DoS

Badacze Nethermind zalewali jednordzeniowy węzeł Nethermind nieudanymi transakcjami walidacyjnymi na trzech maszynach o różnej wydajności, testując limity MAX_VERIFY_GAS od 100 000 do 500 000 gas. Kluczową metryką było to, czy narzut walidacji utrzymywał opóźnienie importu bloku w budżecie 25 ms — progu, poniżej którego uznaje się, że normalne przetwarzanie bloków nie jest dotknięte równoległym obciążeniem mempoolu. Pełne opracowanie ukazało się na forum Ethereum Research.

Bez ochrony po stronie klienta wyniki były ograniczające. Na najwolniejszym profilu pełnego węzła budżet 25 ms opóźnienia importu był utrzymany tylko do około 15 milionów gas walidacji na sekundę. Przy floodzie 100 nieudanych transakcji na sekundę ten sufit przepustowości pozostawiał w budżecie tylko limit 100 000 gas — co oznacza, że każde podniesienie limitu umożliwiające rzeczywistą walidację kryptograficzną stworzyłoby również działający wektor DoS na sprzęcie typowym dla domowych operatorów węzłów.

Benchmark ocenia dwie odrębne osie zdrowia mempoolu: bezpieczeństwo przetwarzania bloków (czy narzut walidacji opóźnia import bloku?) oraz sprawiedliwość przyjmowania transakcji (czy uczciwi nadawcy nadal trafiają ze swoimi transakcjami ramkowymi do mempoolu, gdy atakujący zalewa sieć?). Te dwie osie nie poruszają się razem — dlatego mechanizm ochrony nie rozwiązuje całego problemu, nawet gdy dobrze radzi sobie z pierwszą osią.

Mechanizm ochrony i jego koszt resztkowy

Proponowana ochrona w kliencie jest prosta: wstrzymaj walidację mempoolu, gdy węzeł przetwarza przychodzący blok. To rozdziela dwa obciążenia konkurujące o ten sam rdzeń CPU, zapobiegając sytuacji, w której flood walidacyjny zjada budżet czasu potrzebny importowi bloku. Przy aktywnej ochronie benchmark raportuje, że opóźnienie importu spadło do około 2 ms lub mniej na każdej testowanej maszynie, pozwalając limitowi 300 000 gas przy floodzie 100 transakcji na sekundę pozostać w budżecie przetwarzania bloków wynoszącym 25 ms. Nethermind ma otwarty pull request implementujący to zachowanie priorytetyzacji.

Mechanizm wstrzymania rozwiązuje problem importu bloków, ale nie problem sprawiedliwego przyjmowania transakcji. Przy floodzie 100 transakcji na sekundę i limicie 300 000 gas najwolniejsza testowana maszyna przyjmowała jedynie 12% uczciwych transakcji ramkowych. Gdy węzeł wstrzymuje walidację, aby przetwarzać bloki, flood atakującego wypełnia kolejkę walidacji w przerwach, a uczciwe transakcje są wypierane. Budżet przetwarzania bloków 25 ms jest zachowany, ale użyteczność mempoolu dla uprawnionych nadawców transakcji ramkowych gwałtownie spada pod stałą presją atakującego.

Ten kolaps przyjmowania jest strukturalnie podobny do dynamiki spamu w mempoolu, która dotykała Ethereum w okresach mintowania NFT o wysokich opłatach lub aktywności botów arbitrażowych. EIP-8141 czyni jednak atak tańszym w utrzymaniu, ponieważ przeciwnik musi jedynie generować transakcje, które docierają do walidacji, a nie transakcje włączane on-chain. Ponieważ transakcje nie przechodzą walidacji, nie niosą dla atakującego żadnego kosztu włączenia poza zużytym gasem na walidację — czyli dokładnie tym zasobem, który protokół próbuje ograniczyć.

Co wyniki mogą oznaczać dla klientów Ethereum i operatorów węzłów

Benchmark wyznacza wiarygodną ścieżkę do limitu 300 000 gas — wystarczająco wysokiego dla transakcji prywatności Groth16, ale nie dla najdroższych wariantów SPHINCS+ — pod warunkiem, że każdy główny klient Ethereum wdroży ochronę priorytetu przetwarzania bloków. To wymóg koordynacji, a nie reguła protokołu: sam EIP nie nakazuje zachowania klienta, tylko ustawia sufit gas. Jeśli mniejszość węzłów zostanie wdrożona bez ochrony, te węzły staną się nieproporcjonalnie dużymi celami podczas floodu. Ten ciężar koordynacji jest amplifikowany przez wielokliencką architekturę Ethereum, w której kilka niezależnych zespołów utrzymuje oprogramowanie węzłów, a zachowanie całej sieci zależy od tego, że każda implementacja dostarczy równoważne zabezpieczenia.

Dla operatorów węzłów korzystających ze sprzętu z dolnej granicy testowanego zakresu benchmarku — maszyny jednorzeniowej o ograniczonej przepustowości pamięci — wynik przyjmowania uczciwych transakcji na poziomie 12% podczas floodu oznacza, że transakcje ramkowe mogą stać się skutecznie zawodne w okresach obciążenia atakującego, nawet na w pełni zaktualizowanym kliencie. Ma to największe znaczenie dla aplikacji zależnych od szybkiego przyjęcia do mempoolu, takich jak wrażliwe na czas przepływy transakcji prywatnych czy protokoły koordynacji podpisów progowych. Projektanci protokołów budowanych na EIP-8141 powinni uwzględniać wrogie warunki mempoolu w założeniach o żywotności, podobnie jak protokoły DeFi takie jak Aave traktują ryzyko opóźnienia likwidacji jako funkcję obciążenia sieci, a nie stałą.

Benchmark nie ocenia limitów powyżej 300 000 gas jako wykonalnych przy obecnym projekcie ochrony przy 100 nieudanych transakcjach na sekundę. Osiągnięcie sufitu 500 000 gas — który pomieściłby najcięższe warianty SPHINCS+ — wymagałoby silniejszego limitowania tempa na warstwie propagacji transakcji, filtrowania spamu opartego na stawce lub niższego założenia bazowego tempa floodu. Każda z tych opcji wiąże się z dodatkową złożonością protokołu i koordynacją między klientami wykraczającą poza to, co określa obecny draft EIP-8141.

Status draftu i otwarte pytania

EIP-8141 nadal ma status Draft, a wyniki benchmarku wprost zasilają trwającą dyskusję o parametrach, nie rozstrzygając jej. Zgodnie z procesem EIP propozycje na etapie Draft przechodzą jeszcze przez Review i Last Call, zanim osiągną status Final, co pozostawia parametry takie jak MAX_VERIFY_GAS otwarte na zmiany w oparciu o właśnie tego typu wkład badawczy. Deweloperzy klientów i autorzy EIP będą musieli zważyć koszt uczciwego przyjmowania przy limicie 300 000 gas względem zastosowań kryptograficznych wymagających wyższych budżetów i ustalić, czy ochrona priorytetu przetwarzania bloków jest wystarczającą samodzielną mitigacją, czy dodatkowe mechanizmy odporności na spam należą do rdzenia propozycji.

Wynik 12% przyjęć na najwolniejszej maszynie prawdopodobnie będzie punktem centralnym tej dyskusji: protokół, który przy umiarkowanym floodzie przyjmuje mniej niż jedną na osiem uczciwych transakcji, oferuje istotnie słabsze gwarancje żywotności niż obecny mempool, nawet jeśli sam finałowość bloków nie jest dotknięta. Wątek na forum Ethereum Research i otwarty pull request Nethermind to dwa udokumentowane miejsca, w których ta ocena będzie się dalej toczyć.