Ethereum Block Building: l'economia nascosta dietro ogni transazione

Block Building è un aspetto cruciale del ciclo di vita di Ethereum, costituito da varie parti mobili. Determina quali transazioni vengono incluse in un blocco e in quale ordine, con un impatto diretto sull'efficienza della rete, la decentralizzazione e l'equità. Nel tempo, il processo di produzione dei blocchi di Ethereum si è evoluto, soprattutto con il ruolo crescente di MEV e il passaggio dalla selezione guidata dal validatore ai costruttori specializzati.

In questo post analizzeremo l'evoluzione dell'Ethereum Block Building, con l'introduzione della Proposer Builder Separation e la ricerca futura.

Introduzione ai componenti di Ethereum Block Building

Slot ed Epoche

Ethereum organizza il tempo in unità discrete:

• Slot: uno slot è un periodo di 12 secondi in cui può essere proposto un singolo blocco. Se nessun validatore invia un blocco all'interno di uno slot, questo viene saltato.
• Epoca: un'epoca è composta da 32 slot, per un totale di 6,4 minuti .

Alla fine di ogni epoca, i compiti del validatore vengono rimescolati per garantire decentralizzazione e sicurezza. Ethereum raggiunge la finalità economica dopo 2 epoche (~12,8 min) , dopodiché è quasi impossibile ripristinare i blocchi.

Comitati

Ethereum ha un numero enorme di Validatori nella rete. Al momento in cui scrivo, ci sono 1.051.349 validatori attivi secondo beaconcha.in Sarebbe irrealizzabile se così tanti validatori dovessero verificare ogni blocco ogni 12 secondi. Quindi, i validatori sono divisi in comitati per convalidare in modo efficiente le transazioni e attestare la validità del blocco.

Ogni comitato:

• Consiste in un sottoinsieme di validatori assegnati in modo casuale all'inizio di un'epoca utilizzando RANDAO.
• Garantisce che nessun singolo validatore abbia un'influenza sproporzionata.
• Partecipa alla votazione (attestazione) dei blocchi e ne conferma la validità.

La dimensione di un comitato dipende dal numero totale di validatori attivi nella rete, ma in genere ogni comitato ha almeno 128 validatori.

In ogni slot:

• Ci sono diciamo N Comitati assegnati per slot e diciamo che ci sono M Validatori in ogni Comitato (dove M >128). Ciò significa che ci sono attestazioni NxM per ogni slot. Come puoi capire, può diventare rapidamente opprimente per la rete spettegolare su così tante attestazioni.

• Gli Aggregatori in ogni Comitato hanno il compito di aggregare le attestazioni del rispettivo Comitato. Ciò significa che da un Comitato di M Validatori, c'è solo 1 Aggregated Attestation finale invece di M .

• Quindi in ogni slot, ci sono una finale di N Attestazioni (1 per ogni comitato di quello slot) che vengono spettegolate sull'argomento globale. Il Proponente dello slot successivo raccoglie queste N attestazioni.

  
  

Alcuni punti da tenere a mente

• Durante un'epoca, ogni validatore attivo è membro di un solo comitato, quindi tutti i comitati dell'epoca sono disgiunti.

• Il protocollo adatta il numero totale di comitati in ogni epoca in base al numero di validatori attivi.

• Il progetto attuale prevede 64 comitati per slot, ovvero N=64

  
  

Proponente Lookahead

Il beacon chain shuffling è progettato per fornire un minimo di 1 Epoch (32 slot) di anticipazione sui prossimi incarichi del comitato del validatore per l'attestazione dettati dal shuffling e dallo slot. Si noti che questo anticipazione non si applica alla proposta, che deve essere verificata durante l'epoca in questione.

get_committee_assignment può essere chiamato all'inizio di ogni epoca per ottenere l'assegnazione per l'epoca successiva ( current_epoch + 1 ). Ciò consente inoltre ai validatori di calcolare l'ID della subnet, di unirsi al rispettivo comitato e di essere preparati per i loro compiti.

Inoltre, un Validator potrebbe essere assegnato come Aggregator di un comitato specifico. In tal caso, deve anche sottoscrivere il rispettivo argomento.

Responsabilità del proponente

All'interno di ogni slot, un singolo validatore del rispettivo comitato viene selezionato come proponente per creare e inviare un blocco.

Il ruolo del proponente è fondamentale in quanto:

• Costruisci un blocco includendo transazioni e attestazioni in sospeso.
• Firma e trasmetti il SignedBeaconBlock alla rete.
• Ottieni ricompense proponendo con successo blocchi validi.

Breve introduzione su MEV

MEV è il profitto aggiuntivo estratto dai validatori (ex minatori) riordinando, includendo o censurando le transazioni all'interno di un blocco.

Alcune strategie MEV comuni sono:

• Front-running : piazzare un trade appena prima di una transazione redditizia nota. Il frontrunning è anche considerato un MEV tossico poiché sorprende l'utente con un effetto negativo.
• Back-running : esecuzione di una transazione subito dopo un evento specifico (ad esempio, bot di arbitraggio).
• Attacchi sandwich : una combinazione di front-running e back-running, soprattutto nelle negoziazioni DeFi.

Chi estrae il MEV?

• Validatori (pre-PBS) : quando i validatori controllavano la produzione dei blocchi, avevano piena discrezionalità sull'ordinamento delle transazioni e potevano estrarre direttamente MEV.
• Ricercatori : attori indipendenti che analizzano il mempool alla ricerca di opportunità MEV e inviano le transazioni di conseguenza.
• Costruttori (post-PBS) : dopo il PBS, i costruttori di blocchi assumono il ruolo di costruire blocchi ottimizzati per MEV, mentre i validatori selezionano semplicemente i blocchi dal miglior offerente.

Costruzione di blocchi pre-PBS: MEV incentrato sul validatore

Prima che Ethereum passasse a PBS, il proponente (in precedenza i minatori in PoW) aveva il pieno controllo sull'ordinamento delle transazioni . Ciò ha creato un ecosistema in cui MEV veniva estratto direttamente dai validatori o esternalizzato a ricercatori specializzati.

Come funzionava prima del PBS:

1. Pool di transazioni : le transazioni vengono trasmesse come di consueto ed entrano nel mempool.
2. I validatori selezionavano manualmente le transazioni dal mempool. Queste potevano essere ordinate in base a qualcosa chiamato priority_fee , ovvero le commissioni che l'utente è disposto a pagare per essere incluso per primo. Potrebbero anche essere ordinate in modo che il validatore guadagni di più (tramite sandwich/frontrunning).
3. Il Validatore costruisce il blocco in base alle transazioni selezionate.
4. Propagazione del blocco : il blocco firmato viene trasmesso alla rete.

Questo è un po' vagamente astratto per semplificare. Ma questo era il flusso generale. Questo può essere definito come Vanilla Block Building

Problemi con la costruzione di blocchi pre-PBS

• Centralizzazione dell'energia MEV : i validatori di grandi dimensioni avevano un vantaggio economico rispetto a quelli più piccoli grazie alla loro capacità di estrarre MEV in modo più efficiente.
• Aumento del rischio di censura : i validatori potrebbero scegliere di escludere le transazioni che non sono in linea con i loro incentivi finanziari.
• Congestione della rete e tariffe elevate del gas : le guerre di offerte per le transazioni MEV hanno portato a un utilizzo inefficiente dello spazio a blocchi, aumentando i costi per gli utenti abituali.

Block Building Post-PBS: separazione tra proponenti e costruttori

Per affrontare i rischi di centralizzazione e le inefficienze della costruzione di blocchi controllata dal validatore, è stata introdotta la Proposer-Builder Separation (PBS) . La PBS suddivide le responsabilità della produzione di blocchi tra due entità separate:

1. Costruttori di blocchi : entità specializzate nella costruzione di blocchi ottimizzati, che spesso incorporano strategie MEV.
2. Proponenti di blocchi (validatori) : i validatori non costruiscono più i blocchi da soli; selezionano semplicemente il blocco più redditizio offerto dai costruttori.

Come funziona dopo PBS:

1. I costruttori costruiscono blocchi : i costruttori di blocchi competono per realizzare il blocco più redditizio, tenendo conto delle opportunità di estrazione di MEV.
2. Offerta per l'inclusione in blocchi : i costruttori presentano un'offerta per proporre il loro blocco ai validatori, garantendo che questi ricevano l'opzione più redditizia.
3. I validatori selezionano l'offerta più alta : invece di selezionare singole transazioni, i validatori scelgono semplicemente il builder's block con l'offerta più alta, massimizzando così le loro ricompense.

Come funziona ora la creazione di blocchi Ethereum

1. L'utente invia la transazione tramite il portafoglio connesso a JSON-RPC.
2. Questa transazione viene inviata al mempool pubblico. Tutte le transazioni vengono scaricate qui prima di essere prelevate e convalidate. Di recente, i Private Orderflow hanno preso il sopravvento e la maggior parte dei grandi player ha optato per questo, poiché è una soluzione alternativa per trasmettere le tue transazioni al pubblico tramite canali autorizzati/privati. Dai un'occhiata alla dashboard su Dune per maggiori informazioni.

3. Searchers → che sono entità esterne che scansionano il mempool continuamente per trovare opportunità MEV ( maggiori informazioni di seguito ). Recuperano le rispettive transazioni e inseriscono le proprie se e quando necessario per realizzare un profitto. Quindi, creano un bundle di queste transazioni, il cui ordine deve essere mantenuto per tutto il tempo affinché il Searcher realizzi un profitto. I bundle sono transazioni ordinate che devono essere eseguite atomicamente. Insieme a questo bundle, possono aggiungere una transazione alla fine del bundle che denota una "tangente" al Builder. Questo bundle viene inviato al Builder tramite la chiamata eth_sendBundle .

   Nota : i ricercatori sono entità esterne e influenzano l'ordinamento delle transazioni, ma non partecipano alla convalida dei blocchi o alle decisioni consensuali.

   

   
   

4. Builder →La successiva entità è il Builder, che in realtà costruisce il blocco. Cercano di massimizzare sia le entrate delle commissioni che le entrate MEV. Includono le transazioni in bundle inviate dai Searcher (si spera in ordine) e accettano il pagamento (tangente) inviato dai Searcher. I Builder costruiscono i payload di esecuzione utilizzando le transazioni ricevute.

   Riempiono i blocchi con:

   1. Pacchetti inviati dai Cercatori.

   2. Transazioni ad alta priorità.

   3. Ordina le transazioni generali tenendo presente di massimizzare i ricavi.

      
      

   Impostano anche il campo feeRecipient sul proprio indirizzo, il che significa che riceveranno sia le tangenti del Searcher sia tutte le commissioni dalle transazioni nel loro blocco inviato. I Builder inviano una transazione alla fine del loro blocco che funge da tangente per il proponente, in modo simile a ciò che il Searcher ha fatto per il Builder.

   
   

5. Relay → Il mercato dei costruttori è un mercato competitivo con vari costruttori che vogliono che i loro payload siano finalizzati per guadagnare le commissioni. Tuttavia, la maggior parte dei blocchi viene costruita da alcuni noti Block Builder, vale a dire BeaverBuild e Titan. Per semplificare questo processo per il Proponente effettivo, i Relay sono entità intermedie che convalidano i payload inviati dai vari Builder e scelgono quello con il profitto/offerta massimi. La comunicazione Relay-Proponente utilizza un trucco simile a un Commit and Reveal per garantire che il Proponente non imbrogli ogni entità fino a questo punto. Maggiori informazioni qui .

Mettendolo insieme

Comunicazione del proponente del relè

È del tutto possibile che, ricevendo il payload del blocco, il proponente scarti il blocco, inserisca le sue transazioni e modifichi l'ordinamento a proprio piacimento, oltre a impostare feeRecipient sul proprio indirizzo. Ciò significherebbe che ogni singola entità che ha lavorato al processo di creazione del blocco fino ad ora (Searcher → Builder → Relay) verrà imbrogliata o farà "MEV stealing". Per evitare ciò, il Relay invia solo l'Header del Block Payload selezionato. Ciò accade quando il proponente effettua la chiamata eth_getPaylaodHeader . Il Relay ora invia un PayloadHeader che contiene l'hash del corpo, l'offerta e la firma del builder.

Il proponente ha a questo punto 2 opzioni:

• Per selezionare il PayloadHeader (chiamato anche Blinded Block ) fornito dal Relay. In tal caso, il proponente deve firmare l'intestazione con la propria chiave e inviarla al Relay e di conseguenza richiedere il PayloadBody tramite la chiamata eth_returnSignedHeader . Ora il Relay esegue la chiamata eth_sendPayload che restituisce l'intero ExecutionPayload al proponente. Il Proponer quindi propone semplicemente questo blocco alla rete Ethereum Validator o più specificamente al comitato a cui è stato assegnato.

  
  

• Il Proponente può scegliere di non accettare il PayloadHeader inviato dal Relay, nel qual caso deve costruire il blocco da solo. Ciò include trovare opportunità MEV e ordinare le transazioni di conseguenza. Naturalmente, in questo caso, il Proponente riesce a mantenere l'intero ricavo dalle commissioni + MEV. Tuttavia, non è così semplice come sembra. Trovare MEV e ottimizzare i ricavi è un compito piuttosto elaborato e c'è la possibilità che il proponente non riesca a costruire il blocco in tempo (12 secondi), quindi ci sarà uno slot perso. In questo scenario, il proponente potrebbe essere tagliato fuori dalla rete.

Ma nel Caso 1, cosa succede se il Proponente non invia il blocco inviato dal Relay?

Bene, il proponente è tenuto a firmare il PayloadHeader proprio per questo motivo. Prima di inviare l'Header, il Relay invia il PayloadBody a un Escrow per la custodia. Una volta che il Relay riceve il PayloadHeader firmato dal proponente, verifica la firma e invia il PayloadBody memorizzato nell'escrow al Proponente. Ora, supponiamo che il proponente non includa questo Block. Crea il suo blocco, ignorando l'ordinamento fatto finora. In questo caso, la firma non corrisponderà poiché le intestazioni sono cambiate.

Il Builder può ora trasmettere queste intestazioni firmate in conflitto alla rete e il Proponente può essere escluso dalla rete.

Cosa impedisce ai costruttori di censurare le transazioni?

Beh, niente. Il motivo più comune per cui i Builder potrebbero censurare una transazione è perché interagisce con gli indirizzi OFAC . Per semplificare, gli indirizzi OFAC interagiscono con transazioni che potrebbero avere ripercussioni legali, cosa che ovviamente nessuno vorrebbe sulla propria testa.

Secondo Censorship.pics, i blocchi creati dai costruttori includono solo lo 0-7% di transazioni sanzionate dall'OFAC.

Come possiamo risolvere questo problema?

Una delle soluzioni più note alla censura delle transazioni al momento in cui scrivo sono Inclusion Lists .

Gli elenchi di inclusione sono un elenco di transazioni (insieme a qualcosa chiamato Riepilogo) che vengono pubblicate dal Proponente dello Slot N insieme alla proposta del Blocco dello Slot N.

Le liste di inclusione impongono che le transazioni nella lista debbano essere incluse nel Blocco N o nel Blocco N+1, altrimenti il blocco N+1 non sarà valido. Queste sono chiamate liste di inclusione in avanti.

Naturalmente, questa progettazione degli IL non consentirà una resistenza alla censura del 100%, ma sono in corso ricerche attive per rafforzare queste proposte e si possono applicare molte ottimizzazioni interessanti per migliorare la struttura degli incentivi.

FOCALE

Le liste di inclusione applicate da Fork Choice (FOCIL) sono un nuovo modello proposto nel 2024 che sviluppa e migliora le liste di inclusione per aumentare la neutralità credibile.

FOCIL consente a più Validatori di fornire suggerimenti sull'Inclusion List per uno slot specifico. Per essere più precisi, 16 Validatori vengono scelti casualmente in ogni slot per formare un Inclusion List Committee. Questi membri formano ciascuno il proprio IL locale e lo divulgano alla rete. Il Proponente raccoglie e aggrega gli elenchi di inclusione locali disponibili in un IL finale. I progetti IL sono leggeri poiché non è necessario ricostruire il blocco per includere queste transazioni; possono semplicemente essere aggiunti al blocco. La condizione affinché un Blocco soddisfi il requisito di convalida IL è " Il blocco è valido se contiene tutte le transazioni da tutti gli IL finché il blocco non è pieno".

Vantaggi del PBS per la gestione MEV

• Decentralizzazione dell'estrazione MEV : i costruttori di blocchi, anziché pochi grandi validatori, gestiscono l'estrazione MEV, riducendo i rischi di centralizzazione dei validatori. Tuttavia, questa è un'arma a doppio taglio poiché nel processo di mitigazione della centralizzazione dei validatori, abbiamo introdotto la centralizzazione dei costruttori, in cui solo pochi costruttori costruiscono una grande percentuale di blocchi.
• Distribuzione più equa dei ricavi : i validatori continuano a trarre profitto da MEV senza impegnarsi direttamente nell'estrazione, rendendo più equa la produzione dei blocchi.
• Utilizzo più efficiente dello spazio nei blocchi : la concorrenza tra costruttori porta a blocchi ottimizzati con una migliore efficienza del gas.

Le sfide del PBS

• Rischio di centralizzazione tra i costruttori : sebbene i validatori siano decentralizzati, alcuni costruttori dominanti potrebbero comunque centralizzare l'estrazione MEV.
• Fiducia nei relè MEV off-chain : PBS attualmente si basa sui relè MEV-Boost, che operano off-chain, ponendo potenziali rischi per la sicurezza in quanto punto di errore.

Riferimenti:

La separazione tra proponente e costruttore di Ethereum: promesse e realtà

Stato della ricerca: resistenza alla censura sotto PBS

Censura del costruttore: il nucleo marcio di Ethereum

Wiki dell'EPF - PBS

Note su PBS

Elenco di inclusione in avanti

Chi vince le aste di Ethereum Block Building e perché?

FOCALE

Ringraziamenti