Ho visto molti dibattiti sui tempi di slot più veloci (EIP-7782) e sugli epbs (EIP-7732), quindi volevo condividere la mia posizione. Prima di tutto, voglio sottolineare che tutte le discussioni che ho visto sono state in buona fede, tutti vogliono ciò che è meglio per Ethereum. La domanda principale è solo l'ordine delle operazioni. È un buon problema da avere! Dall'esterno potrebbe sembrare disordinato, ma questo è ciò che sembra la R&D pubblica. Siamo in una cucina aperta a dibattere se servire prima la carne o l'aragosta, il cliente ottiene entrambi in ogni caso, è solo una questione di quando e come.
Ora parlando solo per me stesso (non per il mio team), credo che dovremmo spedire prima l'EIP-7732. Ecco perché:
1.) Da una prospettiva ingegneristica, ha più senso ristrutturare prima, poi accorciare. Farlo al contrario non è solo più lavoro ingegneristico, non è 1:1 (non è lineare nemmeno) ma è più difficile da ragionare. 2.) Da una prospettiva di testing, è più semplice testare prima la ristrutturazione degli slot e poi slot più veloci. Come abbiamo visto in Pectra, il testing è il principale collo di bottiglia per la spedizione! 3.) Da una prospettiva di sicurezza, implementare un cambiamento più grande (come la ristrutturazione) prima e poi uno più piccolo (accorciamento) è spesso più sicuro. Lascia che funzioni su mainnet e indurisci prima di aggiungere più complessità. 4.) Da una prospettiva temporale, in termini di tempo combinato, credo che (EIP-7732 → EIP-7782) sia più veloce di (EIP-7782 → EIP-7732). Potremmo spedire 7782 solo 3–4 mesi dopo 7732 se lavoriamo su entrambi in parallelo e passiamo alla modalità di test appena 7732 arriva. Un breve fork solo CL potrebbe portarci rapidamente lì.
Questa è solo la mia opinione come qualcuno che costruisce e implementa queste cose giorno per giorno. Mi manca il contesto sia nella ricerca che nella comunità. In definitiva, gli utenti di Ethereum dovrebbero avere voce in capitolo, preferiresti tempi di slot più veloci a Glamsterdam o un limite di gas di esecuzione più alto e una maggiore capacità di blob? Perché? Mi piacerebbe sentire le tue opinioni.
Non sono riuscito a partecipare alle chiamate ACD quanto avrei voluto, ma la sessione di oggi sembrava super produttiva. Ethereum sta spedendo & scalando!
La coda dei validatori di Ethereum è cresciuta costantemente da fine maggio, ho analizzato tutti i vecchi depositi di esecuzione ETH1 e i nuovi depositi EIP-6110 dal slot 11649077 -> 11931977
Numeri generali: - Ci sono un totale di 82.529 nuovi depositi EL contro 541 vecchi depositi di dati eth1, poiché il deposito eth1 previsto è stato deprecato - Totale di 2,3 milioni di ETH depositati tramite deposito EL - 375 depositi EL superiori a 32 ETH
https://launchpad.ethereum.org/en/validator-actions è criminalmente sottovalutato. L'UX per il deposito parziale, il prelievo e il compounding è super fluido. Grande merito al team dietro di esso, ma come sempre, fai le tue ricerche.
Ho scavato nei blocchi nell'ultimo mese e ho trovato qualcosa di interessante: 172 blocchi non avevano tx, 85 non avevano destinatari di commissione. Sono circa 5–6 al giorno, circa lo stesso tasso delle riorganizzazioni. Esempio: https://t.co/lw0pSAePBt Le riorganizzazioni dell'ultimo minuto potrebbero colpire i costruttori di sorpresa? Qualcuno sa di più? cc @Data_Always
Un mese dall'aggiornamento Pectra. Ho scritto uno script veloce per scaricare tutti i blocchi da & l'utilizzo delle richieste di esecuzione dello studio. Ciò che ho trovato in 236k slot:
- Su 236k slot, solo 30.587 blocchi avevano richieste di esecuzione - In quei blocchi, ci sono state 69.041 richieste di deposito, 312 richieste di prelievo (perché così poche!), e 17.570 richieste di consolidamento - Per i depositi, abbiamo visto 57.293 chiavi pubbliche uniche e 2.102 credenziali di prelievo uniche - Per i prelievi, 262 chiavi pubbliche uniche dei validatori e 100 indirizzi sorgente unici - Per il consolidamento, 3.422 indirizzi di destinazione unici e 3.544 auto-consolidamenti, che sembrano essere ~1,3% dei validatori consolidati