Ethereum valuta un mempool crittografato con EIP dedicato contro front running e censure

Nella community di Ethereum è in discussione un nuovo EIP per introdurre un mempool crittografato a livello di protocollo, con l’obiettivo di limitare front running, sandwiching e rischi di censura.

Obiettivi e contesto della proposta

Il nuovo EIP mira a integrare nel protocollo un mempool con transazioni cifrate fino all’inclusione in blocco. L’intento è proteggere gli utenti da riordini malevoli delle transazioni e rafforzare la resistenza alla censura in tempo reale, senza puntare alla privacy completa.

Le transazioni, infatti, vengono rivelate pubblicamente una volta incluse nella blockchain. Inoltre, la proposta punta a ridurre i rischi regolamentari per block builder e altri operatori, che restano temporaneamente “accecati” dal contenuto delle operazioni fino alla pubblicazione delle chiavi di decrittazione.

Il lavoro si inserisce nel solco di esperimenti precedenti come lo Shutterized Beacon Chain e l’implementazione già attiva su Gnosis Chain, dove è presente un mempool cifrato fuori protocollo. Secondo gli autori, il meccanismo affronta il problema storico del front running e può attenuare effetti collaterali del MEV, come la centralizzazione dei builder.

Integrazione con la roadmap e con ePBS

La proposta è pensata per integrarsi in modo naturale con la proposer-builder separation enshrined (ePBS) prevista nella roadmap di Ethereum. In questo quadro, la separazione strutturale tra chi propone e chi costruisce i blocchi si combina con un layer di cifratura che limita la visibilità anticipata sul contenuto delle transazioni.

Detto ciò, le transazioni in chiaro restano supportate, in modo da garantire la continuità operativa della rete. Anche in caso di malfunzionamenti o fallimenti dei fornitori di chiavi, la progressione della catena viene preservata, evitando blocchi o interruzioni del consenso.

Struttura tecnica: registro dei key provider

Nello strato di esecuzione viene introdotto un contratto dedicato, il key provider registry. Qualsiasi account può registrarsi come fornitore di chiavi, ottenendo un ID univoco. In fase di registrazione è necessario indicare un contratto con due funzioni: decrittazione e validazione chiave, entrambe parametrizzate da key ID e messaggio.

I fornitori possono inoltre marcare altri provider come “direttamente fidati”, costruendo così un grafo di fiducia diretto. Un provider A è considerato fidarsi di B se esiste un cammino diretto da A a B. La Beacon Chain replica lo stato del registro, analogamente a quanto avviene per la gestione dei depositi.

In questo modo, l’infrastruttura rimane agnostica rispetto alla tecnologia crittografica utilizzata: sono ammessi modelli basati su threshold encryption, MPC, TEEs, delay encryption o FHE. Tuttavia, molti di questi schemi sono poco efficienti da esprimere in EVM e richiederebbero precompilati dedicati, lasciati fuori dallo scope dell’EIP.

Nuovo tipo di transazione cifrata

Il protocollo introduce un nuovo tipo di transazione: quella crittografata. Questa è composta da una busta (envelope) e da un payload cifrato. La busta contiene envelope nonce, gas, parametri di prezzo del gas, ID del key provider, key ID e firma dell’envelope.

Il payload crittografato include invece il payload nonce, il valore trasferito, la calldata e la firma sul payload. Inoltre, il modello prevede regole precise sull’ordinamento in blocco: una transazione cifrata con chiave di un provider A può essere preceduta solo da transazioni in chiaro, da transazioni cifrate con chiavi di A o di provider che A considera fidati.

In ogni slot, quando un key provider osserva il payload di esecuzione pubblicato dal builder, raccoglie tutti i key ID relativi alle transazioni cifrate indirizzate a sé. Per ciascuno di essi deve pubblicare o la chiave di decrittazione corrispondente o un avviso di trattenimento della chiave.

Ruolo del Payload Timeliness Committee e attestazioni

Il messaggio che trasporta le chiavi fa riferimento all’hash del blocco beacon, per impedire riutilizzi in slot futuri. I provider possono pubblicare le chiavi non appena osservano il payload di esecuzione, oppure ritardare la pubblicazione a un momento successivo all’interno dello stesso slot.

I membri del Payload Timeliness Committee (PTC) devono monitorare le chiavi di decrittazione relative a tutte le transazioni cifrate, identificate da ID del provider e key ID. Successivamente, devono validare tali chiavi usando la funzione di validazione del registry, con un piccolo limite di gas predefinito per ciascuna chiave.

Infine, il PTC deve attestare la presenza o l’assenza di una chiave valida per ogni transazione cifrata, estendendo il messaggio di attestazione del payload con un apposito bitfield. In questo modo la rete dispone di un registro on-chain dello stato delle chiavi in ciascun blocco.

Esecuzione delle buste e dei payload cifrati

Durante l’elaborazione del payload di esecuzione, dopo tutte le transazioni in chiaro, le buste delle transazioni cifrate vengono eseguite in batch. Ciò aggiorna i nonce dei firmatari e paga le commissioni a partire dagli account associati alle envelope.

Le fee coprono il consumo di spazio di blocco utilizzato da buste, payload decrittati e chiavi, oltre al calcolo per decrittazione e validazione. Successivamente, i payload vengono decrittati usando la chiave identificata da key provider ID e key ID, attraverso la funzione di decrittazione nel registry.

Se la decrittazione va a buon fine, le transazioni risultanti vengono eseguite entro il gas indicato sulle buste e nel rispetto del block gas limit. Tuttavia, se decrittazione o esecuzione falliscono, oppure se il PTC attesta l’assenza di chiave valida, il payload viene saltato senza rollback sull’envelope.

Scelte di design e impatto sull’ordine delle transazioni

La registrazione dei key provider è volutamente agnostica rispetto allo schema crittografico, per garantire neutralità e basse barriere all’ingresso. Inoltre, la scelta di usare un contratto nello strato di esecuzione fornisce un modo canonico per definire logica arbitraria, anche se una gestione solo sulla consensus layer sarebbe possibile.

Il grafo di fiducia tra provider risponde a un’esigenza competitiva. Se ciascun utente si fidasse solo del proprio provider, i builder potrebbero includere in ogni blocco transazioni cifrate legate a un solo soggetto, favorendo il rischio di monopolio. La gestione della fiducia da parte dei provider riduce complessità per gli utenti.

Inoltre, la proposta segmenta di fatto il blocco in due sezioni: transazioni in chiaro e transazioni cifrate. Le prime vengono inserite per prime, così che i builder possano simularne l’esecuzione e applicare le tecniche attuali di costruzione dei blocchi e di estrazione di MEV.

Garanzie sui pagamenti di gas e decrittazione delle transazioni

Questa struttura consente ai builder di aggiungere le transazioni cifrate in coda senza costi di opportunità. Se l’ordine fosse invertito, le fee per le transazioni crittografate dovrebbero essere molto più alte per rendere i blocchi competitivi rispetto a quelli solo in chiaro.

Per evitare che vengano inclusi payload incapaci di pagare il gas, il pagamento delle commissioni avviene interamente tramite l’envelope e tutte le buste sono eseguite prima dei payload. Tale scelta elimina i rimborsi di gas, garantendo al builder e al protocollo un ricavo certo al momento della costruzione del blocco.

Per semplicità, il payload include una firma dedicata. In alternativa, meno privata ma più efficiente, si potrebbe considerare il firmatario dell’envelope come mittente della transazione, riducendo la complessità crittografica.

Gestione del withholding delle chiavi di decrittazione

Il protocollo consente esplicitamente ai key provider di trattenere le chiavi di decrittazione secondo condizioni definite da loro. Ciò permette di applicare regole di accesso, ad esempio legate a pagamenti precedenti, o di prevenire specifici attacchi, come quello sul key ID.

D’altra parte, le chiavi trattenute senza giustificazione possono essere utilizzate in meccanismi personalizzati di slashing o in metriche di affidabilità. Il protocollo registra infatti quali chiavi sono state pubblicate e quali no, creando una base dati verificabile per eventuali incentivi economici off-chain.

La proposta non introduce incentivi economici in protocollo per i provider, né punizioni esplicite per comportamenti malevoli. Ciò lascia spazio a modelli di business diversi: accordi con builder, pagamenti per transazione da parte degli utenti o gestione come bene pubblico.

Ipotesi future: cifratura del payload di esecuzione

In prospettiva, un successivo EIP potrebbe consentire ai builder di usare le stesse chiavi per cifrare direttamente il payload di esecuzione. In questo scenario, i builder potrebbero pubblicare il payload appena costruito, anziché attendere la metà dello slot, migliorando l’efficienza del p2p.

Inoltre, unito a una prova a conoscenza zero sulle chiavi usate nel blocco, questo meccanismo permetterebbe di anticipare l’inizio della finestra temporale di rivelazione delle chiavi, allungandola complessivamente. Tuttavia, tali estensioni sono volutamente escluse dalla proposta attuale per contenere la complessità.

Nel complesso, l’EIP introduce modifiche non retrocompatibili sia allo strato di esecuzione sia al consensus layer, richiedendo quindi un hard fork coordinato per l’eventuale attivazione.

Rischi di sicurezza e fiducia nei key provider

Per quanto riguarda la sicurezza, gli utenti devono necessariamente fidarsi dei provider scelti per cifrare le transazioni, sia per evitare la pubblicazione anticipata delle chiavi, che abiliterebbe front running e sandwiching, sia per prevenire ritardi che bloccherebbero l’esecuzione pur facendo pagare l’envelope.

Questa fiducia può basarsi su meccanismi crittografici, come threshold o hardware encryption, su meccanismi economici, come lo slashing, oppure su governi di tipo sociale, ad esempio con voto per selezionare entità considerate affidabili.

In misura minore, chi invia transazioni cifrate deve fidarsi anche dei provider usati per le transazioni precedenti nel blocco. Infatti, questi ultimi possono scegliere se pubblicare o trattenere le proprie chiavi dopo aver visto le chiavi relative alle transazioni successive, ottenendo un margine di influenza sullo stato precedente.

Attacchi potenziali: da reorg a key ID front running

Le azioni dei provider possono diventare più pericolose se vengono adottati schemi di “decrittazione” malevoli, tali da permettere modifiche mirate al risultato usando chiavi opportunamente costruite. In casi estremi, ciò consentirebbe di impostare direttamente il contenuto del payload, aprendo la strada a sofisticate forme di front running.

Gli utenti non devono invece fidarsi dei provider utilizzati per transazioni successive, perché lo stato precedente alle loro operazioni non dipende dai payload seguenti. Inoltre, chi invia transazioni in chiaro resta esposto alla sola fiducia nel builder, come nel modello attuale.

Un ulteriore rischio riguarda le reorg: le chiavi vengono pubblicate prima che le transazioni corrispondenti siano finalizzate. In caso di riorganizzazione della catena, una transazione potrebbe diventare pubblica senza essere inclusa. Tuttavia, poiché il messaggio di chiave include l’hash del blocco, la funzione di validazione può invalidarlo nel nuovo contesto.

Misure contro gli attacchi sul key ID

Questo meccanismo non impedisce l’inclusione dell’envelope, ma blocca l’esecuzione del payload, prevenendo il front running. Resta però un vettore di attacco specifico, il key ID front running, in cui un attore osserva una transazione cifrata in transito e invia una seconda transazione che usa lo stesso provider e key ID.

Se questa seconda operazione venisse inclusa prima, un provider ingenuo rivelerebbe la chiave, esponendo il contenuto della transazione originale ancora non inclusa. Per mitigare l’attacco, i provider possono adottare la “namespacing” dei key ID, rilasciando chiavi solo per ID prefissati con l’indirizzo del firmatario dell’envelope.

Poiché è ragionevole assumere che l’attaccante non abbia accesso a quell’account, non sarebbe in grado di creare una transazione con un key ID correttamente namespacizzato. In questo modo, il rischio di key ID front running viene sostanzialmente ridotto.

Collusione tra key provider e builder

Un altro scenario di rischio è la collusione tra key provider e builder. Per costruire un nuovo blocco, questi ultimi devono conoscere il post-stato del blocco precedente, quindi tutte le chiavi usate e quelle trattenute, informazione che diventa pubblica una volta che il PTC ha attestato.

Un provider malevolo potrebbe però dare un preavviso a un builder specifico, concedendogli un vantaggio competitivo nell’avvio della costruzione del blocco. Secondo l’analisi degli autori, l’impatto è limitato, perché l’intervallo tra pubblicazione delle attestazioni e fine dello slot è ritenuto sufficiente per il block building.

Inoltre, l’inizio della finestra di costruzione è meno critico della fine, quando è noto il set completo di transazioni includibili. Ritardare la pubblicazione delle chiavi aumenta anche il rischio che non vengano attestate dal PTC, azzerando il vantaggio dell’attaccante, soprattutto se il numero di transazioni legate al provider colluso è ridotto.

Implicazioni complessive per Ethereum

Complessivamente, la proposta EIP mempool crittografato punta ad aumentare la protezione degli utenti da front running e sandwiching, ridurre la centralizzazione legata al MEV e migliorare la resistenza alla censura in tempo reale. Tuttavia, introduce nuovi livelli di complessità e dipendenza da infrastrutture di key management esterne.

Rispetto allo status quo, il meccanismo sposta parte della fiducia dagli attori di mercato, come i builder, ai key provider, che diventano soggetti critici dal punto di vista sia tecnico sia di governance. La discussione in corso nella community determinerà se, quando e con quali modifiche questa architettura potrà essere effettivamente adottata sulla mainnet di Ethereum.