I ricercatori di Nethermind, sviluppatore di client Ethereum, hanno pubblicato un benchmark che esamina quanto grande possa crescere il budget di validazione definito dal parametro MAX_VERIFY_GAS di EIP-8141 prima che i nodi Ethereum si espongano ad attacchi di denial-of-service (DoS) sul mempool. Il risultato centrale dello studio è che una protezione a livello di client — la sospensione della validazione del mempool durante l'elaborazione di un blocco — è la differenza tra un limite di 300.000 gas sostenibile e una configurazione che esaurisce le risorse del nodo sotto un flood avversario prolungato.

Cosa è destinato a vincolare il budget di validazione di EIP-8141

EIP-8141 è una proposta Core Standards Track in stato di bozza intitolata "Frame Transaction". Secondo lo scopo dichiarato, la proposta aggiunge un livello di astrazione di frame per la validazione delle transazioni, l'esecuzione e il pagamento del gas, consentendo alle transazioni di includere logica di validazione personalizzata prima di essere ammesse al mempool ed eventualmente incluse in un blocco. Il testo della proposta è disponibile nel repository EIP di Ethereum. Il mempool è la coda in cui i nodi trattengono le transazioni che hanno superato la validazione in attesa di essere incluse in un blocco, ed è per questo che il calcolo nella fase di ammissione è il punto focale della preoccupazione DoS discussa in questo articolo.

Il budget di validazione — definito da un parametro chiamato MAX_VERIFY_GAS — stabilisce quanto calcolo un nodo deve eseguire per ammettere una singola frame transaction. Con un limite di 100.000 gas per transazione, l'attuale bozza è troppo bassa per accogliere casi d'uso reali: una singola spesa privacy Groth16 richiede 211.828 gas per la validazione, e le varianti di firma SPHINCS+ richiedono fino a 276.000 gas. Il limite deve quindi crescere per diventare pratico, ma ogni revisione al rialzo amplia la superficie di attacco disponibile per avversari disposti a inondare i nodi di transazioni costose e destinate a fallire.

La tensione progettuale è familiare a chiunque abbia seguito il dibattito sull'account abstraction di EIP-4337: il lavoro di validazione che avviene fuori dal percorso di esecuzione è economico da innescare per gli attaccanti ma costoso da assorbire per i nodi. EIP-8141 sposta quel lavoro in un budget imposto dal protocollo, che almeno rende il costo delimitato. Dove collocare quel limite, tuttavia, comporta un compromesso diretto tra ricchezza di funzionalità e resilienza del mempool.

EIP-8141 resta una proposta in bozza e non è attivata su nessuna rete Ethereum attiva. I risultati del benchmark sono un contributo di ricerca alla discussione progettuale, non una descrizione di una configurazione deployata.

Come il benchmark misura l'esposizione al DoS sul mempool

I ricercatori di Nethermind hanno inondato un nodo Nethermind a un solo core di transazioni di validazione fallimentari su tre macchine di prestazioni diverse, testando limiti MAX_VERIFY_GAS compresi tra 100.000 e 500.000 gas. La metrica centrale era se l'overhead di validazione mantenesse la latenza di importazione dei blocchi entro un budget di 25 ms — la soglia sotto la quale l'elaborazione normale dei blocchi si considera non influenzata dal carico di lavoro simultaneo del mempool. Il testo completo è pubblicato sul forum Ethereum Research.

Senza protezione lato client, i risultati sono stati limitanti. Sul profilo di full node più lento, il nodo è rimasto entro il budget di 25 ms di ritardo di importazione solo fino a circa 15 milioni di gas di validazione al secondo. Con un tasso di flood di 100 transazioni fallimentari al secondo, quel tetto di throughput ha lasciato entro il budget solo il limite di 100.000 gas — il che significa che qualsiasi aumento del limite che consenta la validazione crittografica reale creerebbe anche un vettore DoS praticabile su hardware tipico dei gestori di nodi domestici.

Il benchmark valuta due distinti assi di salute del mempool: la sicurezza dell'elaborazione dei blocchi (l'overhead di validazione ritarda l'importazione dei blocchi?) e l'equità di ammissione delle transazioni (i mittenti onesti riescono ancora a far entrare le loro frame transaction nel mempool quando un avversario inonda la rete?). Questi due assi non procedono insieme, ed è per questo che il meccanismo di protezione non risolve l'intero problema anche quando gestisce bene il primo asse.

Il meccanismo di protezione e il suo costo residuo

La protezione proposta nel client è semplice: sospendere la validazione del mempool mentre il nodo elabora un blocco in arrivo. Questo separa i due carichi di lavoro che competono per lo stesso core CPU, impedendo a un flood di validazioni di erodere il budget di tempo necessario all'importazione dei blocchi. Con questa protezione attiva, il benchmark riporta che il ritardo di importazione è sceso a circa 2 ms o meno su ogni macchina testata, consentendo a un limite di 300.000 gas sotto un flood di 100 transazioni al secondo di rimanere entro il budget di elaborazione dei blocchi di 25 ms. Nethermind ha una pull request aperta che implementa questo comportamento di priorità.

Il meccanismo di sospensione risolve il problema dell'importazione dei blocchi ma non quello dell'equità di ammissione. Sotto un flood di 100 transazioni al secondo con il limite di 300.000 gas, la macchina più lenta testata ha ammesso solo il 12% delle frame transaction oneste. Quando il nodo sospende la validazione per elaborare i blocchi, il flood avversario riempie la coda di validazione negli intervalli, e le transazioni oneste vengono escluse. Il budget di elaborazione dei blocchi di 25 ms è preservato, ma l'utilità del mempool per i mittenti legittimi di frame transaction si degrada fortemente sotto pressione avversaria prolungata.

Questo crollo delle ammissioni è strutturalmente simile alle dinamiche di spam sul mempool che hanno colpito Ethereum durante i periodi di mint NFT con commissioni elevate o attività di bot di arbitraggio. EIP-8141, tuttavia, rende l'attacco più economico da sostenere, perché l'avversario deve solo generare transazioni che raggiungano la validazione, non transazioni incluse on-chain. Poiché le transazioni falliscono la validazione, non comportano per l'attaccante alcun costo di inclusione al di là del gas consumato per ogni validazione — che è esattamente la risorsa che il protocollo cerca di delimitare.

Cosa potrebbero significare i risultati per i client Ethereum e gli operatori di nodi

Il benchmark stabilisce un percorso credibile verso un limite di 300.000 gas — abbastanza elevato da supportare le transazioni privacy Groth16 ma non le varianti SPHINCS+ più costose — a condizione che ogni principale client Ethereum implementi la protezione con priorità all'elaborazione dei blocchi. Si tratta di un requisito di coordinamento, non di una regola del protocollo: l'EIP stesso non impone il comportamento del client e stabilisce solo il tetto di gas. Se una minoranza di nodi viene rilasciata senza la protezione, quei nodi diventano bersagli sproporzionati durante un flood. Quell'onere di coordinamento è amplificato dall'architettura multi-client di Ethereum, in cui diversi team indipendenti mantengono il software dei nodi e il comportamento a livello di rete dipende dal fatto che ogni implementazione fornisca protezioni equivalenti.

Per gli operatori di nodi che utilizzano hardware nella fascia bassa della gamma testata dal benchmark — una macchina a un solo core con larghezza di banda di memoria limitata — il risultato del 12% di ammissione di transazioni oneste in condizioni di flood significa che le frame transaction possono diventare di fatto inaffidabili durante periodi di congestione avversaria, anche su un client completamente aggiornato. Questo conta soprattutto per le applicazioni che dipendono da un'ammissione tempestiva al mempool, come i flussi di transazioni private sensibili al tempo o i protocolli di coordinamento delle firme a soglia. I progettisti di protocolli che costruiscono sopra EIP-8141 dovrebbero incorporare le condizioni avversarie del mempool nelle ipotesi di liveness, allo stesso modo in cui protocolli DeFi come Aave trattano il rischio di latenza di liquidazione come funzione della congestione della rete piuttosto che come costante.

Il benchmark non valuta come sostenibili limiti superiori a 300.000 gas con l'attuale design di protezione a 100 transazioni fallimentari al secondo. Raggiungere il tetto di 500.000 gas — che accoglierebbe le varianti SPHINCS+ più onerose — richiederebbe un rate-limiting più forte a livello di propagazione delle transazioni, un filtraggio dello spam basato sullo stake o un'ipotesi di tasso di flood base più basso. Ciascuna di queste opzioni comporta una complessità protocollore aggiuntiva e un coordinamento tra client che va oltre quanto specificato dall'attuale bozza di EIP-8141.

Stato di bozza e questioni aperte

EIP-8141 è ancora in stato di bozza, e i risultati del benchmark alimentano direttamente la discussione in corso sui parametri senza risolverla. Secondo il processo EIP, le proposte in stato di bozza attraversano ancora le fasi di Review e Last Call prima di raggiungere lo stato Final, lasciando parametri come MAX_VERIFY_GAS aperti a revisione sulla base esattamente di questo tipo di contributo di ricerca. Gli sviluppatori di client e gli autori dell'EIP dovranno valutare il costo in termini di ammissioni oneste del limite di 300.000 gas rispetto ai casi d'uso crittografici che richiedono budget più elevati, e determinare se la protezione con priorità all'elaborazione dei blocchi sia sufficiente come mitigazione autonoma o se ulteriori meccanismi di resistenza allo spam debbano far parte della proposta core.

La figura del 12% di ammissione sulla macchina più lenta sarà probabilmente un punto focale di quella discussione: un protocollo che ammette meno di una transazione onesta su otto sotto un flood moderato offre garanzie di liveness sensibilmente più deboli rispetto all'attuale mempool, anche se la finalità dei blocchi in sé non è influenzata. Il thread sul forum Ethereum Research e la pull request aperta di Nethermind sono i due luoghi documentati in cui quella valutazione continuerà a svilupparsi.