I validatori di Ethereum sono destinati ad assumere nuovi ruoli con l'introduzione di EIP-7732, la proposta di separazione Enshrined Proposer-Builder.
Questa proposta cambia radicalmente il modo in cui i blocchi Ethereum vengono convalidati separando la convalida dell'esecuzione dalla convalida del consenso sia logicamente che temporalmente.
I validatori vengono revisionati
I validatori ora hanno nuove responsabilità, inclusa la possibilità di diventare costruttori e l’obbligo di presentare attestazioni di tempestività del carico utile.
L’EIP affronta molteplici questioni chiave nel sistema attuale. La maggior parte dei proponenti di blocchi beacon affidano la costruzione del carico utile di esecuzione a una terza parte, nota come costruttore.
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 carico utile di esecuzione completo del costruttore prima della trasmissione.
L'EIP garantisce scambi equi tra il proponente del blocco beacon e il costruttore. Garantisce che un onesto proponente di un blocco beacon venga pagato dal costruttore e che il carico utile di un costruttore onesto diventi il capo canonico della catena.
Attualmente, i validatori hanno una finestra breve per eseguire transizioni sia di consenso che di stato di esecuzione, verificare la disponibilità dei dati blob e valutare il nuovo capo della blockchain.
Questo EIP cambia la situazione separando l’esecuzione e la convalida del consenso, consentendo ai validatori di concentrarsi sulla transizione dello stato di consenso prima di attestare.
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 dell'intero carico utile di esecuzione dal blocco di consenso consente una propagazione della rete più rapida. 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 inoltre la necessità di un middleware affidabile per la delega della costruzione di blocchi.
L'EIP non richiede modifiche al livello di esecuzione. Tuttavia, il livello di consenso subisce diverse modifiche, dettagliate nel repository GitHub delle specifiche di consenso.
Questi includono modifiche alla Beacon Chain, scelta del fork, protocolli P2P, guide di validazione e l'introduzione di una nuova guida per il builder.
Le modifiche alla catena Beacon coinvolgono costanti, preimpostazioni e varie classi contenitore per gestire le nuove attestazioni del payload e le intestazioni del payload di esecuzione firmate.
Il contenitore BeaconState viene modificato per tenere traccia dell'ultimo hash del blocco, dell'ultimo slot con un payload di esecuzione e dell'ultima root dei prelievi.
BeaconBlockBody ora include un'intestazione del payload di esecuzione firmata e un elenco di attestazioni del payload. ExecutionPayloadHeader è semplificato per tenere traccia delle informazioni minime per gli impegni di carico utile del builder.
Le modifiche alla logica di transizione dello stato includono nuove funzioni per l'elaborazione delle attestazioni del payload, delle intestazioni del payload di esecuzione e delle richieste di prelievo.
Le modifiche alla scelta del fork implicano nuove costanti e classi contenitore per gestire i nodi figlio, i messaggi più recenti e memorizzare le modifiche. Vengono introdotti nuovi gestori per i messaggi di attestazione del payload e le buste del payload di esecuzione firmate.
Segnalazione di Jai Hamid