Il percorso di Ethereum verso la resistenza alla censura: BRAID vs. FOCIL

Nel panorama in evoluzione di Ethereum, la battaglia per la resistenza alla censura ha introdotto diversi meccanismi innovativi. Tra questi, BRAID e FOCIL si distinguono come due approcci promettenti progettati per proteggere l’integrità della rete riducendo al minimo il rischio di censura delle transazioni.

Entrambe le soluzioni affrontano questioni critiche nel processo di proposta di blocco, ma adottano approcci fondamentalmente diversi per raggiungere i loro obiettivi. Questo articolo approfondisce le sfumature di questi due meccanismi e analizza quale potrebbe rivelarsi più efficace.

Comprendere la minaccia della censura in Ethereum

Al centro del processo di generazione e convalida dei blocchi di Ethereum ci sono due attori principali: i costruttori e i proponenti. I costruttori sono responsabili dello smistamento delle transazioni e della presentazione di un blocco ai proponenti, che selezionano un blocco da firmare e proporre alla blockchain.

Questo processo, tuttavia, crea una potenziale vulnerabilità. Poiché i proponenti hanno l’ultima parola su quale blocco viene proposto, esiste il rischio di collusione tra proponenti e costruttori per censurare alcune transazioni, minacciando così il principio di resistenza alla censura di Ethereum.

La resistenza alla censura è fondamentale per mantenere l’equità e la trasparenza della blockchain. Se i proponenti possono includere o escludere selettivamente le transazioni, ciò mina la natura decentralizzata della rete e può portare allo sfruttamento dell’ordine delle transazioni, con conseguenti problemi come il Miner Extractable Value (MEV).

Soluzioni esistenti: MCP e FOCIL

Per affrontare questa sfida, sono state proposte diverse soluzioni resistenti alla censura, tra le quali le più discusse sono i meccanismi della Force Inclusion List (FOCIL) e del Multi-Concurrent Proposer (MCP).

Elenco di inclusione della forza (FOCIL)

Il FOCIL è progettato per garantire l’equità coinvolgendo un comitato di validatori selezionati a caso durante ogni fascia oraria.

Questi validatori creano elenchi di inclusione locali basati sulla loro visione del mempool e trasmettono questi elenchi.

Il proponente aggrega quindi questi elenchi locali in un elenco di inclusione finale che viene aggiunto al blocco.

Questo meccanismo garantisce che nessun singolo proponente abbia il pieno controllo sulle transazioni incluse in un blocco, riducendo così il rischio di censura.

I validatori verificano che il blocco aderisca alle regole del consenso prima di accettarlo nella blockchain.

Proponente Multi-Concorrente (MCP)

L’MCP introduce il concetto di più proponenti simultanei, come suggerito per la prima volta da Max Resnick nel meccanismo della molteplicità.

In questo sistema, diversi proponenti lavorano in parallelo, ciascuno selezionando una porzione di transazioni dal mempool.

Queste transazioni vengono confezionate in “pacchetti di transazioni speciali” e firmate dai proponenti. Per essere considerato valido, il proponente principale deve includere almeno due terzi di questi pacchetti nel blocco proposto.

Questo metodo decentra il potere di un singolo proponente e riduce significativamente la probabilità di censura delle transazioni.

BRAID: Un’implementazione MCP migliorata

Basandosi sul concetto di MCP, Max Resnick ha sviluppato ulteriormente BRAID, un’implementazione MCP più sofisticata e completa.

Presentato durante il seminario “DeFi in MEV Era” ospitato da Paradigm, BRAID consente a più proponenti di proporre blocchi su diverse catene parallele contemporaneamente.

Questi blocchi vengono poi sincronizzati attraverso un meccanismo di consenso per garantire la coerenza tra le catene.

Il livello di esecuzione di Ethereum consolida tutti i blocchi generati all’interno dello slot in un unico blocco di esecuzione, dove le transazioni vengono deduplicate, ordinate ed eseguite secondo regole predefinite.

Questo approccio riduce significativamente il potere di ogni singola entità di manipolare i record delle transazioni.

Un vantaggio fondamentale di BRAID è quello di evitare ruoli aggiuntivi o complesse strutture di incentivi, che possono aggiungere complessità.

Tuttavia, coordinare la sincronizzazione tra più sottocatene e gestire l’elaborazione dei dati pone delle sfide.

Sfide e considerazioni in BRAID

Nonostante i suoi punti di forza, BRAID non è privo di problemi. Una sfida notevole è rappresentata dal modello di “mancia condizionale”, che richiede agli utenti di disporre di liquidità per garantire che le loro transazioni siano resistenti alla censura. Gli utenti devono impostare due valori di mancia quando inviano le transazioni:

1. Punta superiore (T): L’importo massimo che un utente è disposto a pagare per assicurarsi che la sua transazione sia inclusa anche in caso di tentativo di censura. Se un solo proponente include la transazione, riceve l’intero importo di T.
2. Punta inferiore (t): una mancia più piccola che viene pagata se più proponenti includono la transazione. In questo caso, la mancia viene distribuita tra i proponenti che includono la transazione.

Questo modello, pur essendo efficace per scoraggiare la censura, introduce ulteriori complessità e costi per gli utenti. Al momento della transazione, infatti, essi devono riservare liquidità extra, che può essere congelata fino a quando non si determina se sarà necessaria.

Per affrontare questi problemi, Jonahb di Blockchain Capital suggerisce due potenziali soluzioni:

• Prova di liquidità post-statale: Questo approccio consente agli utenti di dimostrare che avranno liquidità sufficiente per pagare la mancia più alta dopo l’esecuzione della transazione. Tuttavia, ciò richiede che i proponenti comprendano lo stato successivo alla transazione, il che è difficile nelle transazioni che coinvolgono uno stato condiviso o operazioni finanziarie complesse.
• Assicurazione contro la censura: Questo concetto introduce fornitori terzi di assicurazione contro la censura (CI) che garantiscono la mancia dell’utente in cambio di un compenso. Questo riduce l’onere immediato di liquidità per gli utenti, ma richiede lo sviluppo di un mercato tra utenti e fornitori di CI.

Prospettive comunitarie: FOCIL vs. BRAID

La comunità di Ethereum è divisa sui meriti relativi di FOCIL e BRAID. Terence, uno sviluppatore del client Ethereum Prysm, apprezza il fatto che BRAID non richieda ulteriori partecipanti, semplificando il processo rispetto a FOCIL, che introduce vincoli di tempo aggiuntivi per la presentazione e la verifica delle liste di inclusione. Tuttavia, FOCIL è generalmente considerato più facile da implementare e più flessibile.

Dan Robinson, ricercatore di Paradigm, elogia BRAID per il suo approccio alla prioritizzazione delle transazioni, che riduce efficacemente i rischi di MEV. Sottolinea inoltre che il meccanismo di ribaltamento condizionato è un forte incentivo contro la censura, un aspetto che manca a FOCIL.

Al contrario, lo sviluppatore Dev preferisce FOCIL per la sua semplicità e la robusta resistenza alla censura, suggerendo che FOCIL offre un’implementazione più semplice con meno complicazioni.

Il ricercatore di Ethereum barnabe.eth riconosce che, sebbene BRAID possa offrire miglioramenti in alcune aree, è cauto nell’abbandonare completamente il modello basato sul leader su cui sono costruiti FOCIL e altri progetti di IL, citando la necessità di ulteriori ricerche e prove per validare la fattibilità di BRAID.

Conclusione: Quale meccanismo è superiore?

Il dibattito tra BRAID e FOCIL sottolinea la complessità di raggiungere la resistenza alla censura in Ethereum. L’approccio innovativo di BRAID alla decentralizzazione del potere dei proponenti e alla riduzione del rischio di MEV è convincente, ma comporta notevoli sfide di implementazione e richiede ulteriori sviluppi.

FOCIL, pur essendo più semplice e flessibile, potrebbe non offrire lo stesso livello di robustezza contro tentativi sofisticati di censura.

In definitiva, la scelta tra BRAID e FOCIL può dipendere dalle priorità specifiche della rete Ethereum in un determinato momento. Con l’evoluzione dell’ecosistema, entrambi i meccanismi potrebbero svolgere un ruolo nel rafforzare la resistenza di Ethereum alla censura, garantendo che la rete rimanga fedele ai suoi principi decentralizzati.