Il background e la motivazione dell'EIP-7732
Poiché i problemi del MEV sono difficili da risolvere alla radice, adottare misure per garantire condizioni di parità è l’unico modo per evitare rischi per la sicurezza. Dopo la fusione di Ethereum, al fine di mantenere l’equità e ridurre l’effetto di scala dei grandi pledge pool sull’estrazione di MEV, Flashbots ha lanciato MEV-Boost, che utilizza il meccanismo PBS (Proposer-Builder Separation) per ridurre le opportunità per i validatori di partecipare direttamente nelle attività MEV e convertire la diversità delle parti interessate MEV. Attualmente, la percentuale di blocchi MEV-Boost ha superato il 90%.
Con l'adozione diffusa di MEV-Boost, la comunità di Ethereum ha iniziato a preoccuparsi dei rischi per la sicurezza che potrebbero derivare dall'affidarsi a questo servizio di terze parti. Pertanto, è nata l'idea di implementare PBS all'interno del protocollo di Ethereum, chiamato ePBS (. Separazione Proponente-Costruttore). Recentemente, a ePBS è stato assegnato un numero EIP ufficiale: EIP-7732. EIP-7732 è una modifica al livello di consenso senza richiedere modifiche al livello di esecuzione. L’obiettivo principale è separare logicamente e temporalmente la verifica dell’esecuzione dalla verifica del consenso e rinviare la verifica dell’esecuzione fino al completamento della verifica del consenso.
La proposta di EIP-7732, oltre a risolvere il problema dei verificatori che si affidano a terze parti (come MEV-Boost) per costruire carichi utili di esecuzione, mira anche a ottimizzare l'efficienza del processo di verifica. Gli attuali validatori devono completare tutto il consenso ed eseguire le funzioni di transizione di stato in un tempo molto breve (entro 4 secondi), il che richiede risorse di calcolo e larghezza di banda di rete estremamente elevate. Durante questo periodo finestra, i validatori devono verificare e confermare una grande quantità di informazioni sulle transazioni e aggiornare lo stato della blockchain, il che non solo aumenta il carico computazionale di un singolo nodo, ma aumenta anche la possibilità di errori. Separando la verifica dell'esecuzione e la verifica del consenso, si garantisce che i nodi debbano completare solo un numero relativamente limitato di attività all'interno della finestra critica di 4 secondi, riducendo così il carico computazionale e accelerando la propagazione della rete.
Il contenuto principale di EIP-7732
EIP-7732 crea un nuovo ruolo "Builder", una nuova responsabilità opzionale per i validatori che può essere utilizzata da qualsiasi validatore con fondi sufficienti per puntare sulla catena di beacon e la capacità di eseguire attività di costruzione di blocchi. Diventa un costruttore. Il costruttore è responsabile della costruzione e della presentazione delle promesse per l'esecuzione del carico utile. I validatori possono ora esternalizzare l’esecuzione dei payload ai builder, concentrandosi maggiormente sulle attività a livello di consenso.
Il payload di esecuzione è la parte centrale del blocco e contiene tutte le informazioni sulla transazione e sulla modifica dello stato. Il processo di creazione di un carico utile di esecuzione include la selezione delle transazioni dal pool di memoria, l'ordinamento delle transazioni, l'esecuzione delle transazioni in sequenza e il confezionamento di tutte le informazioni per formare un carico utile di esecuzione.
Per ottenere questa separazione, EIP-7732 rimuove il campo ExecutionPayload, che contiene tutti i dati relativi all'esecuzione delle transazioni, come l'elenco delle transazioni e i risultati della transizione di stato. Rimuovendo questo campo, la creazione e la verifica del contenuto di esecuzione vengono separate dalla creazione e verifica del blocco beacon. In alternativa, EIP-7732 introduce una nuova struttura dati, SignedExecutionPayloadHeader, che include la promessa del costruttore di un carico utile di esecuzione che verrà rivelato in futuro.
processo complessivo
Compiti del builder: il builder è responsabile della creazione del payload di esecuzione e della generazione di una promessa che esporrà il payload di esecuzione. La promessa è incapsulata in una struttura dati SignedExecutionPayloadHeader, che include un hash del payload di esecuzione e una firma digitale di questo hash per garantire l'immutabilità dei dati e la verifica dell'origine. Questa promessa indica che il costruttore esporrà il carico utile di esecuzione completo in un determinato momento futuro e specifica un importo da pagare al proponente del blocco beacon per incentivare il proponente del blocco beacon a includere questa promessa.
I compiti del proponente del blocco beacon: Il proponente del blocco beacon (validatore) collabora con il costruttore e non ha bisogno di occuparsi direttamente dei dettagli di esecuzione della transazione quando crea un nuovo blocco beacon, ma include invece l'impegno fornito dal costruttore, e poi trasmettere l'intero blocco beacon alla rete Ethereum per raggiungere il consenso. Includere solo gli impegni riduce il carico sulla rete e accelera la propagazione dei blocchi beacon e il processo di verifica del consenso. Dopo che l'impegno del costruttore è stato elaborato, la mancia nell'impegno viene dedotta dal saldo della catena di beacon del costruttore e accreditata al proponente del blocco di beacon. Dopo che un proponente di un blocco beacon ha trasmesso con successo un blocco beacon con un impegno, il costruttore è tenuto a esporre il payload di esecuzione completo entro un intervallo di tempo specificato.
Verifica PTC: per monitorare se i builder eseguono pubblicamente i payload in modo tempestivo, un gruppo di validatori selezionati casualmente dalla rete Beacon Chain forma il Payload Timeiness Committee (PTC). Il PTC è responsabile di verificare se il builder ha esposto un payload di esecuzione che corrisponde alla promessa entro l'intervallo di tempo specificato. Se il costruttore non comunica in modo tempestivo e corretto, PTC trasmetterà un risultato negativo e il costruttore dovrà affrontare una penalità di riduzione della puntata. Se la verifica PTC ha esito positivo, la verifica completa del payload di esecuzione viene rinviata per essere elaborata separatamente durante il successivo blocco beacon, ovvero la verifica differita.
Inoltre, la proposta introduce anche norme normative e un nuovo meccanismo sanzionatorio per PTC per garantire il rigore e l’equità dell’intero processo di verifica. Allo stesso tempo, a causa della separazione dei payload di esecuzione e dei blocchi beacon, anche la logica di selezione del fork è stata adattata per adattarsi al nuovo processo di verifica. Si prevede che questi cambiamenti miglioreranno significativamente la sicurezza e l’efficienza della rete. Attraverso una serie di progetti, EIP-7732 migliora l'efficienza di elaborazione di Ethereum e riduce la latenza della rete.
