I documenti su realtime_sendRawTransaction e le query di log paginati sono attivi. I crediti vanno a @0xSami_M! Stiamo lavorando a una revisione del sito web della documentazione.

Bunny ha bisogno di un po' d'ombra

E.V.M. parallelo (Ethereum Veggie Machine)

Non sono così sicuro al riguardo. Anche il PoW si basa, in ultima analisi, sull'assunzione che l'avversario non possa controllare grandi quantità di infrastruttura fisica (CPU, GPU, ASIC, SSD, fornitura di elettricità, ecc.) per lunghi periodi di tempo, il che è un'assunzione economica. Sia il PoW che il PoS delegano il difficile problema della mitigazione di Sybil a regole, modelli e euristiche del mondo off-chain.

RT @0xBreadguy: Felice che questo post abbia messo in evidenza i Solana shreds (15ms) come il confronto con i blocchi da 10ms di Mega. In qualche modo, finiamo sempre in questo...

Le conversazioni sono rapidamente convergenti verso la co-progettazione ottimale di CLOB e chain, che era assolutamente prevedibile!!

C'è una riunione settimanale di ingegneria tra GTE e MegaETH. Discutiamo di tutto, dai nuovi metodi RPC (qualcuno ha bisogno di letture paginabili?) a come considerare gli spam sulla blockchain più veloce. Vengo costantemente ricordato di quanto sia talentuosa, ambiziosa e pragmatica la squadra. È stato un vero piacere lavorare con il team di GTE nell'ultimo anno, e questo è solo l'inizio! Congratulazioni a @GTE_XYZ !!

Pup ha dovuto viaggiare per 42 ore solo per arrivare da noi, ed è stato ritardato. Così abbiamo guidato per 3 ore nel mezzo della notte per ridurre le ultime 10 ore. Benvenuto a casa, River!

I sistemi veramente grandi forniscono astrazioni facili da usare per gli utenti finali, mantenendo al contempo tutta la potenza dei meccanismi sottostanti. Il cloud astrae i sistemi operativi e le reti in un enorme computer. La crypto astrae algoritmi distribuiti e teoria dei giochi in un custode benevolo. EigenCloud sta astrando cloud e crypto in una piattaforma di calcolo sempre verificabile e di scala infinita sulla quale tutti possono scaricare tutto. Congratulazioni a @sreeramkannan e al team di @eigenlayer!

L'aggiornamento di questa settimana al testnet MegaETH ha risolto un bug di prestazioni sfuggente che aveva causato un continuo aumento del tempo di miniblock tra i riavvii del sequencer. Ecco la storia. È una storia sulla nostra filosofia: misurare, poi costruire. Se si fosse visitato recentemente il dashboard delle prestazioni di MegaETH, si sarebbe potuto notare che il tempo di miniblock era aumentato durante la settimana che precedeva il 3 giugno. In realtà, tale tendenza sarebbe iniziata subito dopo ogni riavvio del sequencer sin dal lancio del testnet pubblico. In precedenza, i frequenti aggiornamenti al sequencer significavano che il tempo di miniblock non aumentava di alcuna quantità percepibile prima che la tendenza al rialzo venisse ripristinata. Tuttavia, gli aggiornamenti recenti non avevano richiesto riavvii del sequencer, e la tendenza è continuata per settimane. Il 3 giugno, il tempo di miniblock ha quasi raggiunto i 100 ms. Con i riavvii del sequencer che diventano sempre meno probabili in futuro grazie ai backup a caldo, è tempo di eliminare il bug una volta per tutte. Poiché raccogliamo regolarmente molti dati di telemetria per il testnet, il team ha rapidamente iniziato a scavare. La prima scoperta è stata che l'aumento del tempo di miniblock accelerava nel tempo: non solo il tempo di miniblock aumentava, ma aumentava sempre più velocemente. Di solito, tale sintomo implicherebbe che il lavoro coinvolto nella costruzione di ogni miniblock aumentasse in modo superlineare man mano che venivano costruiti più miniblock. Tuttavia, abbiamo scartato l'ipotesi dopo alcune misurazioni e calcoli. Abbiamo costruito la pipeline di miniblock per essere quasi completamente asincrona rispetto all'EVM in modo da ottenere tempi di miniblock arbitrariamente bassi. Ciò significa che, qualunque sia il tempo necessario per costruire un miniblock, l'EVM eseguirà transazioni durante tutto il tempo. Pertanto, un tempo di costruzione del miniblock più lungo porterebbe a un numero maggiore di transazioni per miniblock, ma non abbiamo osservato ciò. Quindi, il problema non può essere nella costruzione dei miniblock. Un'attenta esaminazione del codice conferma questa conclusione: nessuna parte del processo di costruzione del miniblock ha complessità superlineare. Il team ha ampliato la ricerca e il vero colpevole è emerso rapidamente. Il tempo necessario per confermare i blocchi EVM era aumentato; inoltre, il tempo di conferma era perfettamente lineare rispetto al numero di blocchi EVM prodotti dall'ultimo riavvio. Quando si confermano i blocchi EVM, l'ambiente EVM, come l'altezza del blocco, viene aggiornato, quindi l'EVM deve fermarsi e non può eseguire transazioni, il che significa niente miniblock. C'è un intervallo fisso di 1 secondo tra i blocchi EVM. All'interno del budget di 1 secondo, un tempo di conferma che aumenta linearmente porta a una durata di esecuzione delle transazioni che diminuisce linearmente, il che a sua volta porta a un numero di miniblock prodotti che diminuisce linearmente. Se prendiamo il suo reciproco, otteniamo il tempo medio di miniblock, che è inversamente proporzionale nel tempo. È esattamente la forma della funzione che abbiamo visto sul dashboard delle prestazioni. I calcoli sono stati confermati. A quel punto, sapevamo esattamente cosa cercare: qualche procedura il cui carico di lavoro aumenta linearmente nel tempo nella parte particolare del codice che gestisce la conferma dei blocchi EVM. Il resto del lavoro è stato semplice. Il team ha spinto l'aggiornamento questa settimana e il tempo di miniblock non è aumentato. Quindi, qual è stata la lezione? Penso che abbia dimostrato ancora una volta il potere quando l'ingegneria è guidata da misurazioni accurate e principi fondamentali. Il team sta lavorando su altri aggiornamenti con la stessa filosofia. Rimanete sintonizzati!