Ethereum, la bozza EIP-8390 punta a ridurre l’emissione di 33.800 ETH e a sostituire lo Sync Committee

Una nuova proposta per Ethereum, confluita nel repository ufficiale degli EIP, prevede il ritiro dello Sync Committee da 512 validator, l'eliminazione delle relative ricompense e la sostituzione dell'attuale interfaccia light client introdotta con Altair con prove a conoscenza zero off-chain. Secondo la bozza EIP-8390, rimuovere il peso delle ricompense dello Sync Committee ridurrebbe l'emissione annua di consenso di circa 33.800 ETH. Il documento è stato inserito nel repository EIPs alle 02:04 UTC del 24 agosto, ma lo status "Draft" indica che si tratta di una proposta in discussione, non di un aggiornamento adottato: non esistono epoch di attivazione, né un impegno nella roadmap, e la pianificazione viene lasciata ai team client. Nel thread di discussione dell'autore, l'aggiornamento iniziale non riportava review esterne. Lo Sync Committee è un campione di 512 validator i cui messaggi consentono ai light client di seguire la beacon chain in modo compatto, senza dover processare l'intero set di validator. EIP-8390 propone di eliminare questo meccanismo in-protocol prima che siano definiti il servizio sostitutivo di proving, l'interfaccia di migrazione e il relativo supporto economico. Taglio dell'emissione: i numeri della proposta La formula delle ricompense di consenso assegna allo Sync Committee un peso pari a 2 su un denominatore di 64. La rimozione di quel peso senza ridistribuzione comporterebbe una riduzione dell'emissione di consenso pari a 2/64, cioè 1/32. La bozza riporta uno snapshot di 901.505 validator e 42.328.615 ETH in staking. A fronte di una stima di circa 1,082 milioni di ETH di emissione annua di consenso, la quota rimossa equivale a circa 33.800 ETH all'anno. Il calcolo 1/32 non implica un taglio lineare del 3,125% sul rendimento complessivo realizzato da ogni validator: riguarda l'emissione di consenso destinata alle ricompense dello Sync Committee, mentre i rendimenti effettivi possono includere altre componenti di ricompensa di consenso e il reddito dell'execution layer. Sicurezza: da un problema di responsabilità a una nuova dipendenza Altair non definisce una condizione di slashing specifica per un validator che firmi un messaggio malevolo dello Sync Committee. Un'altra proposta, EIP-7657, mirata ad aggiungere tale penalità, risulta ora contrassegnata come "Stagnant". L'EIP avvertiva che applicazioni che mettono in sicurezza più di 512 × 32 ETH, cioè 16.384 ETH, dovrebbero affiancare al protocollo light client ulteriori protezioni. Pur essendo un avvertimento di design basato su un massimo di 32 ETH di effective balance, la soglia riflette la criticità al centro di EIP-8390: le firme campionate aiutano i light client, ma messaggi malevoli dello Sync Committee non hanno una penalità di slashing dedicata a livello di protocollo. Con la rimozione del campione, i light client dovrebbero verificare una prova a conoscenza zero della finality Casper FFG sull'intero set di validator. Questa prova diventerebbe il segnale di finalità per i client che non processano il set completo. Impatto sui light client Altair: rischio di rottura degli attuali flussi EIP-8390 rimuoverebbe i doveri dei validator legati allo Sync Committee, i messaggi di rete, i contenitori dati per i light client e diversi endpoint della Beacon API. La proposta afferma che i light client Altair in produzione che sincronizzano tramite LightClientUpdate smetterebbero di funzionare al fork. La categoria include software che utilizza il flusso standard di aggiornamento Altair. Tra gli esempi citati: Helios, integrabile in wallet e applicazioni decentralizzate, dipende da un endpoint di consenso che supporta la Beacon API light client; Lodestar offre un pacchetto light client lato consumer basato su quel percorso; Nimbus espone un'interfaccia light client sugli stessi oggetti di update; il client Ethereum IBC di Datachain costruisce header da dati LightClientUpdate e FinalityUpdate ottenuti via Beacon RPC. L'impatto effettivo di un eventuale fork dipenderebbe dall'uso attuale delle interfacce rimosse e dalle migrazioni che i maintainer rilasceranno. L'attuale specifica Altair definisce il flusso di update consumato da queste implementazioni. EIP-8390 lo elimina senza introdurre un contratto Beacon API sostitutivo né una specifica di migrazione per i client. ZK proof: prestazioni dichiarate, ma specifiche e incentivi ancora aperti La bozza sostiene che la finality Casper FFG potrebbe essere provata entro un epoch su una GPU e verificata in millisecondi, ma non cita un'implementazione riproducibile, né circuiti, profili hardware o benchmark a supporto. Un design pubblico comparabile sull'intero set di validator riporta un preprocessing sotto il minuto su una CPU a 64 core senza accelerazione GPU e descrive parti della composizione finale della proof come lavoro futuro o non ancora costruito. Il testo non definisce il servizio di proving, l'interfaccia lato client, il modello di affidabilità, gli operatori o le modalità di finanziamento. La bozza aggiunge esplicitamente nessun incentivo in-protocol alla produzione delle proof di finalità e non ne propone, pur lasciando aperta la possibilità di funding off-chain o tramite public goods. In sintesi, il risparmio di emissione è quantificato in modo concreto nei numeri della proposta, mentre disponibilità del sostituto, percorso di migrazione ed economia del proving restano da definire. Per avvicinare EIP-8390 a un'eventuale attivazione servirebbero un'interfaccia testata per i light client, migrazioni funzionanti per gli utilizzatori Altair e una produzione pubblica di proof che rimanga disponibile nel momento in cui gli utenti ne dipendono.