Riepilogo Tecnico: Boost+: Costruzione di Blocchi Equa e Incentivante alla Compatibilità

1. Definizione del Problema

La scarsità di spazio per i blocchi sulle blockchain decentralizzate, in particolare su Ethereum, richiede un'allocazione efficiente attraverso la costruzione dei blocchi (block building). Sebbene il valore estraibile massimo (MEV) guidi la competizione, l'attuale ecosistema, centrato su MEV-Boost, è diventato altamente centralizzato a causa dell'integrazione. L'integrazione si verifica quando i searcher (intermediari che generano transazioni redditizie) indirizzano esclusivamente i loro flussi di ordini verso un singolo builder. Questa pratica crea un vantaggio sleale, distorce la competizione, riduce l'efficienza dello spazio per i blocchi escludendo le transazioni compatibili dai non-integrati e oscura i flussi MEV attraverso pagamenti off-chain opachi.

La sfida principale è progettare un sistema che simultaneamente:

1. Elimini gli incentivi all'integrazione (garantendo l'accesso paritario ai flussi di ordini).
2. Garantisca la compatibilità degli incentivi (rendendo la segnalazione veritiera una strategia dominante sia per i searcher che per i builder).
3. Mantenga l'efficienza economica (costruendo blocchi che massimizzino il benessere sociale).
4. Rimanga computazionalmente fattibile entro i rigorosi vincoli temporali della produzione dei blocchi (ad esempio, slot da 12 secondi).

Proposte esistenti come BuilderNet non riescono a fornire forti garanzie di compatibilità degli incentivi perché non regolano esplicitamente l'interazione tra searcher e builder né impongono regole su come i flussi di ordini debbano essere elaborati.

2. Metodologia: Il Framework Boost+ e il Meccanismo MBoost+

Gli autori propongono Boost+, un sistema che scinde la raccolta delle transazioni dall'esecuzione dell'algoritmo, operando all'interno di un Ambiente di Esecuzione Fidato (TEE) per garantire riservatezza e integrità. Il sistema modella esplicitamente tre attori: Proposer, Builder e Searcher.

Il Meccanismo MBoost+

Il cuore di Boost+ è il meccanismo MBoost+, che opera in due fasi per determinare il blocco finale e l'allocazione del valore:

1. Separazione Libera da Conflitti: Il meccanismo identifica innanzitutto i bundle privi di conflitti (transazioni che non leggono/scrivono su slot di memoria toccati da altre) . Questi vengono separati dal set principale e aggiunti al blocco vincente finale indipendentemente dall'esito, garantendo che siano sempre inclusi con un pagamento netto nullo (il rimborso equivale alla offerta).
2. Esecuzione in Due Fasi:
   • Fase 1 (Algoritmo di Default): Un algoritmo di default (progettato dal sistema) elabora i bundle rimanenti per generare un "blocco di default" ($o^*$) e calcola i blocchi controfattuali ($o_{-i}$) per ogni bundle al fine di determinare i rimborsi. Questa fase stabilisce una base per il benessere e i rimborsi.
   • Fase 2 (Algoritmi dei Builder): I builder inviano i propri algoritmi di costruzione del blocco. Il meccanismo li esegue sullo stesso set di bundle per generare blocchi candidati.
3. Selezione del Vincitore e Pagamento:
   • Il meccanismo confronta l'offerta del blocco di default ($\beta_0$) con le offerte dei blocchi presentati dai builder ($\beta_j$).
   • Se l'algoritmo di default vince: Il meccanismo utilizza il blocco di default. I searcher pagano le loro offerte, ricevono rimborsi calcolati tramite una formula di tipo Vickrey–Clarke–Groves (VCG) basata sui controfattuali del default algorithm, e il proposer riceve l'eccedenza. I builder non ricevono nulla.
   • Se un builder vince: Il builder vincitore paga la sua offerta al meccanismo. Il meccanismo rimborsa i searcher basandosi sui controfattuali dell'algoritmo di default (non di quello del vincitore), garantendo che i searcher non siano penalizzati dall'algoritmo specifico del vincitore. Il builder vincitore riceve un'eccedenza pari alla sua offerta meno la seconda offerta più alta (o l'offerta di default), operando di fatto una asta al secondo prezzo tra i builder.

Garanzie Teoriche

• Builder-DSIC: La segnalazione veritiera è una strategia dominante per i builder, poiché partecipano a un'asta al secondo prezzo con un prezzo di riserva stabilito dall'algoritmo di default.
• Searcher-DSIC (Default-Dominating): Se l'algoritmo di default supera tutti i builder, la segnalazione veritiera è una strategia dominante per i searcher.
• Searcher-DSIC (Conflict-Free): Per i bundle privi di conflitti, la segnalazione veritiera è una strategia dominante in tutti gli scenari, anche se un builder vince.
• Resistenza all'Integrazione: Per i bundle privi di conflitti, la strategia di "partecipare e offrire veritieramente" domina debolmente qualsiasi strategia che preveda l'integrazione con un builder. L'integrazione non offre alcun guadagno di utilità congiunta e può anzi ridurla.

L'Algoritmo di Default

Per garantire la fattibilità computazionale del meccanismo, gli autori propongono un algoritmo di default concreto basato sull'analisi empirica delle transazioni di Ethereum:

• Raggruppamento dei Conflitti: Le transazioni vengono raggruppate in base ai conflitti di lettura/scrittura dello storage.
• Risoluzione Ibrida:
  • Per piccoli gruppi di conflitto (dimensione $< k_{cutoff}$), l'algoritmo esegue un'enumerazione esaustiva per trovare il sottoinsieme ottimale.
  • Per gruppi grandi, applica ottimizzazioni strutturali (ad esempio, se i conflitti sono puramente trasferimenti ERC-20, l'ordine è irrilevante; se si tratta di uno scenario di "sandwich", solo un bundle può vincere).
  • Se nessuna semplificazione è applicabile, seleziona deterministicamente un sottoinsieme di transazioni da mantenere affinché la permutazione sia fattibile.
• Proprietà: L'insieme di blocchi candidati considerato da questo algoritmo è indipendente dalle offerte, un requisito critico per mantenere la compatibilità degli incentivi di tipo VCG.

3. Contributi Chiave

1. Architettura Boost+: Un nuovo sistema di costruzione dei blocchi che governa esplicitamente le interazioni tra searcher e builder, separando la raccolta delle transazioni dall'ordinamento per garantire l'accesso paritario.
2. Meccanismo MBoost+: Un meccanismo che raggiunge la compatibilità degli incentivi per builder e searcher (sotto specifiche condizioni) premiando l'innovazione algoritmica. Decouple con successo il "perfetto" meccanismo VCG (computazionalmente impraticabile) dalla necessità pratica della partecipazione dei builder.
3. Resistenza all'Integrazione per i Conflitti: Dimostrazione teorica che per i bundle privi di conflitti, la non-integrazione combinata con la segnalazione veritiera è una strategia dominante, neutralizzando efficacemente il principale motore della centralizzazione per una significativa classe di transazioni.
4. Algoritmo di Default Informato Empiricamente: Un'implementazione concreta di un algoritmo di default che soddisfa le necessarie proprietà teoriche. La valutazione mostra che costruisce il blocco ottimale nel 53,2% dei casi.

4. Risultati e Valutazione

• Ottimalità: Utilizzando un dataset di 10.000 blocchi di Ethereum (2,9 milioni di transazioni pubbliche, 56 milioni di bundle privati), l'algoritmo di default ha prodotto il blocco di valore più alto nel 53,2% dei casi.
• Gap di Efficienza: Nei casi non ottimali, la differenza assoluta mediana nel valore del blocco è stata di 0,0033 ETH, con una differenza relativa mediana dell'8,6%. Il divario di performance si amplia per i blocchi con alto MEV (valore > 1 ETH), dove l'algoritmo di default raggiunge l'ottimalità solo in circa il 5% dei casi, principalmente a causa della difficoltà di gestire grandi gruppi di conflitto senza ricerca esaustiva.
• Tempo di Esecuzione: L'algoritmo di default sfrutta efficacemente il multi-threading. Con 50 thread, il suo tempo di esecuzione si avvicina a quello degli algoritmi di costruzione dei blocchi paralleli, rendendolo compatibile con gli slot da 12 secondi.
• Analisi dei Conflitti: Lo studio empirico ha rivelato che nella maggior parte dei blocchi, i gruppi di conflitto sono piccoli (spesso di dimensione 1), e i grandi gruppi di conflitto (dimensione $\ge 8$) sono rari (si verificano in meno di 4 gruppi per blocco nella maggior parte dei casi), validando la fattibilità dell'approccio ibrido.

5. Significato e Rivendicazioni

Il paper sostiene che Boost+ offre una soluzione fondata alla centralizzazione e all'inefficienza dell'attuale ecosistema MEV. Esplicitamente modellando l'interazione tra searcher e builder e imponendo un algoritmo di default con set di candidati indipendenti dalle offerte, il sistema:

• Ripristina la Competizione: Rimuove il vantaggio strutturale dell'integrazione per le transazioni prive di conflitti.
• Incentiva l'Innovazione: Premia i builder che sviluppano algoritmi superiori senza compromettere la compatibilità degli incentivi dei searcher.
• Bilancia Teoria e Pratica: Riconosce che raggiungere l'efficienza "perfetta" (massimizzare il benessere sociale) insieme alla compatibilità degli incentivi "perfetta" è computazionalmente intrattabile (NP-hard). Invece, Boost+ offre una soluzione pratica "abbastanza buona" che è provabilmente compatibile con gli incentivi per i builder e per i searcher nei casi più critici (senza conflitti e dominati dal default).

Gli autori concludono che, mentre un meccanismo "perfetto" (solo VCG) è teoricamente pulito ma praticamente inefficiente, e un mercato basato solo sui builder reintroduce i rischi di integrazione, Boost+ trova un equilibrio necessario. Utilizza un algoritmo di default per ancorare la compatibilità degli incentivi e l'efficienza, permettendo al contempo la partecipazione dei builder per elevare il benessere, a patto che il sistema sia in grado di gestire la complessità risultante. Il paper nota che è necessario ulteriore lavoro per affrontare gli attacchi Sybil e per migliorare la gestione dei grandi gruppi di conflitto al fine di aumentare il tasso di ottimalità oltre il 53,2%.