I validatori di Ethereumsono pronti ad assumere nuovi ruoli con l'introduzione di EIP-7732, la proposta Enshrined Proposer-Builder Separation.
Questa proposta modifica radicalmente il modo in cui vengono convalidati i blocchi Ethereum , separando la convalida dell'esecuzione dalla convalida del consenso sia logicamente che temporalmente.
I validatori vengono revisionati
I validatori hanno ora nuove responsabilità, tra cui la possibilità di diventare costruttori e l'obbligo di presentare attestazioni di puntualità del carico utile.
L'EIP affronta diverse problematiche chiave del sistema attuale. La maggior parte dei proponenti di blocchi beacon esternalizza la costruzione del payload di esecuzione a una terza parte, nota come builder.
Richiedono la radice dell'albero hash (HTR) di un payload di esecuzione promesso e inviano un SignedBlindedBeaconBlock a una parte attendibile. Questa parte sostituisce quindi l'HTR con il payload di esecuzione completo del builder prima della trasmissione.
L'EIP garantisce scambi equi tra il proponente del blocco beacon e il costruttore. Garantisce che un proponente onesto del blocco beacon venga pagato dal costruttore e che il payload di un costruttore onesto diventi il capo canonico della catena.
Attualmente, i validatori hanno una finestra temporale breve per eseguire transizioni di stato sia di consenso che di esecuzione, verificare la disponibilità dei dati blob e valutare il nuovo capo della blockchain.
Questo EIP cambia questa situazione separando l'esecuzione dalla convalida del consenso, consentendo ai validatori di concentrarsi sulla transizione dello stato di consenso prima dell'attestazione.
La convalida dell'esecuzione e della disponibilità dei dati viene posticipata, consentendo ai validatori di eseguire queste attività nello slot di tempo rimanente.
Motivazione dietro EIP-7732
La rimozione del payload di esecuzione completo dal blocco di consenso consente una propagazione più rapida in rete. Riduce la probabilità di riorganizzazione quando si includono transazioni blob, a causa delle tempistiche più lunghe per i controlli di disponibilità dei dati.
I validatori non perdono più le attestazioni, rafforzando le proprietà di scelta del fork quando i builder producono payload non validi. L'EIP elimina anche la necessità di un middleware affidabile per la delega della costruzione dei blocchi.
L'EIP non richiede modifiche al livello di esecuzione. Tuttavia, il livello di consenso subisce diverse modifiche, descritte in dettaglio nel repository GitHub consensus-specs.
Tra queste rientrano modifiche alla Beacon Chain, alla scelta del fork, ai protocolli P2P, alle guide per i validatori e all'introduzione di una nuova guida per i builder.
Le modifiche alla catena Beacon riguardano costanti, preset e varie classi di contenitori per gestire le nuove attestazioni del payload e le intestazioni del payload di esecuzione firmate.
Il contenitore BeaconState viene modificato per tracl'ultimo hash del blocco, l'ultimo slot con un payload di esecuzione e la radice degli ultimi prelievi.
BeaconBlockBody ora include un'intestazione del payload di esecuzione firmata e un elenco di attestazioni del payload. ExecutionPayloadHeader è stato semplificato per tracdelle informazioni minime per gli impegni del payload del builder.
Le modifiche alla logica di transizione dello stato includono nuove funzioni per l'elaborazione delle attestazioni del payload, l'esecuzione delle intestazioni del payload e le richieste di prelievo.
Le modifiche alla scelta del fork riguardano nuove costanti e classi contenitore per gestire nodi figlio, messaggi più recenti e modifiche allo store. Sono stati introdotti nuovi gestori per i messaggi di attestazione del payload e per gli envelope del payload di esecuzione firmati.
Reportage di Jai Hamid
