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: 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. Slot: un'epoca è composta da 32 slot, per un totale di . Epoca: 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 , dopodiché è quasi impossibile ripristinare i blocchi. 2 epoche (~12,8 min) Comitati ha un numero enorme di Validatori nella rete. Al momento in cui scrivo, ci sono 1.051.349 validatori attivi secondo Sarebbe irrealizzabile se così tanti validatori dovessero verificare ogni blocco ogni 12 secondi. Quindi, i validatori sono divisi in per convalidare in modo efficiente le transazioni e attestare la validità del blocco. Ethereum beaconcha.in comitati 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 Comitati assegnati per slot e diciamo che ci sono Validatori in ogni Comitato (dove >128). Ciò significa che ci sono attestazioni per ogni slot. Come puoi capire, può diventare rapidamente opprimente per la rete spettegolare su così tante attestazioni. N M M NxM Gli Aggregatori in ogni Comitato hanno il compito di aggregare le attestazioni del rispettivo Comitato. Ciò significa che da un Comitato di Validatori, c'è solo 1 finale invece di . M Aggregated Attestation M Quindi in ogni slot, ci sono una finale di Attestazioni (1 per ogni comitato di quello slot) che vengono spettegolate sull'argomento globale. Il Proponente dello slot successivo raccoglie queste attestazioni. N N 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 comitati per slot, ovvero 64 N=64 Proponente Lookahead Il beacon chain shuffling è progettato per fornire un minimo di di anticipazione sui prossimi incarichi del comitato del validatore per l'attestazione dettati dal shuffling e dallo slot. che questo anticipazione non si applica alla proposta, che deve essere verificata durante l'epoca in questione. 1 Epoch (32 slot) Si noti può essere chiamato all'inizio di ogni epoca per ottenere l'assegnazione per l'epoca successiva ( ). Ciò consente inoltre ai validatori di calcolare l'ID della subnet, di unirsi al rispettivo comitato e di essere preparati per i loro compiti. get_committee_assignment current_epoch + 1 Inoltre, un Validator potrebbe essere assegnato come di un comitato specifico. In tal caso, deve anche sottoscrivere il rispettivo argomento. Aggregator Responsabilità del proponente All'interno di ogni slot, un viene selezionato come per creare e inviare un blocco. singolo validatore del rispettivo comitato proponente Il ruolo del proponente è fondamentale in quanto: Costruisci un blocco includendo transazioni e attestazioni in sospeso. Firma e trasmetti il alla rete. SignedBeaconBlock 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: : 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. Front-running : esecuzione di una transazione subito dopo un evento specifico (ad esempio, bot di arbitraggio). Back-running : una combinazione di front-running e back-running, soprattutto nelle negoziazioni DeFi. Attacchi sandwich Chi estrae il MEV? : quando i validatori controllavano la produzione dei blocchi, avevano piena discrezionalità sull'ordinamento delle transazioni e potevano estrarre direttamente MEV. Validatori (pre-PBS) : attori indipendenti che analizzano il mempool alla ricerca di opportunità MEV e inviano le transazioni di conseguenza. Ricercatori : 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. Costruttori (post-PBS) Costruzione di blocchi pre-PBS: MEV incentrato sul validatore Prima che Ethereum passasse a PBS, il proponente (in precedenza i minatori in PoW) aveva . Ciò ha creato un ecosistema in cui MEV veniva estratto direttamente dai validatori o esternalizzato a ricercatori specializzati. il pieno controllo sull'ordinamento delle transazioni Come funzionava prima del PBS: : le transazioni vengono trasmesse come di consueto ed entrano nel mempool. Pool di transazioni I validatori selezionavano manualmente le transazioni dal mempool. Queste potevano essere ordinate in base a qualcosa chiamato , 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). priority_fee Il Validatore costruisce il blocco in base alle transazioni selezionate. : il blocco firmato viene trasmesso alla rete. Propagazione del blocco 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 : 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. Centralizzazione dell'energia MEV : i validatori potrebbero scegliere di escludere le transazioni che non sono in linea con i loro incentivi finanziari. Aumento del rischio di censura : 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. Congestione della rete e tariffe elevate del gas 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 PBS suddivide le responsabilità della produzione di blocchi tra due entità separate: la Proposer-Builder Separation (PBS) : entità specializzate nella costruzione di blocchi ottimizzati, che spesso incorporano strategie MEV. Costruttori di blocchi : i validatori non costruiscono più i blocchi da soli; selezionano semplicemente il blocco più redditizio offerto dai costruttori. Proponenti di blocchi (validatori) Come funziona dopo PBS: : i costruttori di blocchi competono per realizzare il blocco più redditizio, tenendo conto delle opportunità di estrazione di MEV. I costruttori costruiscono blocchi : i costruttori presentano un'offerta per proporre il loro blocco ai validatori, garantendo che questi ricevano l'opzione più redditizia. Offerta per l'inclusione in blocchi : invece di selezionare singole transazioni, i validatori scelgono semplicemente il builder's block con l'offerta più alta, massimizzando così le loro ricompense. I validatori selezionano l'offerta più alta Come funziona ora la creazione di blocchi Ethereum L'utente invia la transazione tramite il portafoglio connesso a JSON-RPC. Questa transazione viene inviata al mempool pubblico. Tutte le transazioni vengono scaricate qui prima di essere prelevate e convalidate. Di recente, 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 per maggiori informazioni. i Private Orderflow Dune → che sono entità esterne che scansionano il mempool continuamente per trovare opportunità MEV ( ). 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 . Searchers maggiori informazioni di seguito eth_sendBundle : i ricercatori sono entità esterne e influenzano l'ordinamento delle transazioni, ma non partecipano alla convalida dei blocchi o alle decisioni consensuali. Nota →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. Builder Riempiono i blocchi con: Pacchetti inviati dai Cercatori. Transazioni ad alta priorità. Ordina le transazioni generali tenendo presente di massimizzare i ricavi. Impostano anche il campo 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. feeRecipient : i costruttori sono entità esterne e non interagiscono direttamente con la blockchain. Nota → 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 e 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 . Relay BeaverBuild Titan. 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 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 . Il Relay ora invia un che contiene l'hash del corpo, l'offerta e la firma del builder. feeRecipient eth_getPaylaodHeader PayloadHeader Il proponente ha a questo punto 2 opzioni: Per selezionare il (chiamato anche ) 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 tramite la chiamata . Ora il Relay esegue la chiamata che restituisce l'intero al proponente. Il Proponer quindi propone semplicemente questo blocco alla rete Ethereum Validator o più specificamente al comitato a cui è stato assegnato. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Il Proponente può scegliere di non accettare il 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. PayloadHeader Ma nel Caso 1, cosa succede se il Proponente non invia il blocco inviato dal Relay? Bene, il proponente è tenuto a firmare il proprio per questo motivo. Prima di inviare l'Header, il Relay invia il a un per la custodia. Una volta che il Relay riceve il firmato dal proponente, verifica la firma e invia il 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. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Nota è un reato punibile con la multa firmare due intestazioni diverse per lo stesso slot di proposta. 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 i blocchi creati dai costruttori includono solo lo 0-7% di transazioni sanzionate dall'OFAC. Censorship.pics, Come possiamo risolvere questo problema? Una delle soluzioni più note alla censura delle transazioni al momento in cui scrivo sono . Inclusion Lists 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. Gli elenchi di inclusione 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. : esiste anche un concetto per che fa IL per l'attuale Block N stesso. Ma questo progetto aveva difetti economici che portavano a Nota Spot Inclusion Lists Forward Inclusion Lists. 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 sono un nuovo modello proposto nel 2024 che sviluppa e migliora le liste di inclusione per aumentare la neutralità credibile. Le liste di inclusione applicate da Fork Choice (FOCIL) 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". : i membri del comitato IL non possono garantire alcuna forma di ordinamento delle transazioni poiché le transazioni IL possono essere incluse in qualsiasi ordine. Garantiscono solo l'inclusione delle transazioni. Nota Vantaggi del PBS per la gestione 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. Decentralizzazione dell'estrazione MEV : i validatori continuano a trarre profitto da MEV senza impegnarsi direttamente nell'estrazione, rendendo più equa la produzione dei blocchi. Distribuzione più equa dei ricavi : la concorrenza tra costruttori porta a blocchi ottimizzati con una migliore efficienza del gas. Utilizzo più efficiente dello spazio nei blocchi Le sfide del PBS : sebbene i validatori siano decentralizzati, alcuni costruttori dominanti potrebbero comunque centralizzare l'estrazione MEV. Rischio di centralizzazione tra i costruttori : PBS attualmente si basa sui relè MEV-Boost, che operano off-chain, ponendo potenziali rischi per la sicurezza in quanto punto di errore. Fiducia nei relè MEV off-chain 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 Grazie a , e per la revisione e i suggerimenti forniti. @mteam @Gajpower @unnawut
