MegaETH: La Prima Blockchain Real-Time

MegaETH è una blockchain EVM compatibile che porta prestazioni in tempo reale a livello Web2 per la prima volta nel mondo delle criptovalute. Il nostro obiettivo è spingere le prestazioni fino ai limiti dell'hardware, colmando il divario tra le blockchain e i tradizionali server di cloud computing.

MegaETH offre diverse caratteristiche distintive, tra cui un elevato throughput delle transazioni, una capacità di calcolo abbondante e, in modo unico, tempi di risposta a livello di millisecondi anche sotto carico pesante. Con MegaETH, gli sviluppatori possono costruire e comporre le applicazioni più esigenti senza limiti.

Perché il mondo ha bisogno di un'altra blockchain?

L'avanzamento dei framework blockchain ha significativamente abbassato le barriere per la creazione di nuove chain. Di conseguenza, recentemente sono nate un gran numero di nuove chain. Ad esempio, L2Beat ha documentato oltre 120 progetti nell'ecosistema dei Layer-2.

Tuttavia, creare più chain non risolve il problema della scalabilità delle blockchain, poiché ogni chain individuale continua a imporre limitazioni significative sulle dApp che ospita. Ad esempio, la tabella qui sotto mostra il target di gas per secondo e il tempo di creazione del blocco delle principali chain EVM di oggi.

Questa tabella mostra chiaramente che le chain EVM esistenti affrontano limitazioni significative in diversi aspetti. Innanzitutto, tutte mostrano un basso throughput delle transazioni. Ad esempio, sebbene opBNB si distingua per un tasso di gas eccezionalmente alto di 100 MGas/s tra i suoi pari, essa rimane comunque ben al di sotto delle capacità dei moderni server Web2. Per fare un riferimento, 100 MGas/s corrispondono a sole 650 transazioni Uniswap o 3.700 trasferimenti ERC-20 al secondo. Al contrario, i moderni server di database superano già il milione di transazioni al secondo nel benchmark TPC-C.

In secondo luogo, le applicazioni complesse non possono essere portate sulla blockchain a causa della scarsa capacità di calcolo. Ad esempio, un semplice contratto EVM che calcola l'n-esimo numero di Fibonacci consuma circa 5,5 miliardi di gas per n=10⁸, il che richiederebbe all'intera chain opBNB 55 secondi per calcolarlo a 100 MGas/s. Al contrario, un programma simile scritto in C può completare lo stesso compito in soli 30 millisecondi, risultando già 1833 volte più veloce con un singolo core della CPU! Ora immagina le possibilità su una blockchain che sfrutta l'elaborazione multicore per sbloccare una potenza di calcolo 100 volte più grande.

Infine, le applicazioni che richiedono alti tassi di aggiornamento o loop di feedback veloci non sono fattibili con lunghi tempi di blocco. Ad eccezione di Arbitrum One, tutte le chain nella tabella aggiornano i loro stati ogni secondo o più. Tuttavia, applicazioni complesse on-chain, richiedono alti tassi di aggiornamento (ad esempio, intervalli di blocco inferiori a 100 millisecondi) per simulare combattimenti o fisica in tempo reale. Inoltre, il trading ad alta frequenza on-chain non sarebbe possibile a meno che gli ordini non possano essere inviati o annullati entro 10 millisecondi.

Fortunatamente, nessuna di queste limitazioni è insormontabile per le chain EVM. Con i nostri progressi tecnologici, è il momento di costruire una blockchain real-time per sbloccare queste potenzialità. Formalmente, una blockchain real-time è una blockchain in grado di elaborare le transazioni non appena arrivano e pubblicare gli aggiornamenti risultanti in tempo reale. Inoltre, deve supportare un elevato throughput delle transazioni e una capacità di calcolo sostanziale per mantenere l'esperienza in tempo reale anche durante i picchi di richiesta degli utenti.

Specializzazione dei nodi: un cambio di paradigma per i progetti orientati alle prestazioni

La scalabilità delle blockchain è stato un campo di ricerca attivo per molti anni. Allora, come possiamo improvvisamente ottenere miglioramenti delle prestazioni che superino di gran lunga lo stato dell'arte attuale? La risposta è sorprendentemente semplice: delegando la sicurezza e la resistenza alla censura ai layer base come Ethereum e EigenDA, si può esplorare un vasto spazio progettuale per implementare ottimizzazioni aggressive delle prestazioni.

Per comprendere meglio questa idea, cominciamo esaminando come funzionano oggi le blockchain. Ogni blockchain è composta da due componenti fondamentali: il consenso e l'esecuzione. Il consenso determina l'ordine delle transazioni degli utenti, mentre l'esecuzione elabora queste transazioni nell'ordine stabilito per aggiornare lo stato della blockchain.

Nella maggior parte delle blockchain L1, ogni nodo svolge compiti identici senza specializzazione. Ogni nodo partecipa a un protocollo distribuito per ottenere il consenso e poi esegue ogni transazione localmente. Questa configurazione impone un compromesso fondamentale tra prestazioni e decentralizzazione. Ogni L1 deve decidere fino a che punto può aumentare i requisiti hardware per gli utenti regolari che eseguono un nodo, senza compromettere le proprietà fondamentali di una blockchain come la sicurezza e la resistenza alla censura.

È fondamentale per la decentralizzazione della blockchain che gli utenti regolari possano eseguire un nodo.— Vitalik Buterin

Tuttavia, non esiste una risposta definitiva su quali siano i requisiti hardware accettabili per i nodi completi. I diversi L1 si posizionano in modo piuttosto diverso lungo lo spettro tra prestazioni e decentralizzazione. Ad esempio, la seguente tabella mostra le configurazioni hardware consigliate da diversi L1.

Al contrario, i L2 rappresentano un cambio di paradigma nel design delle blockchain, eliminando la necessità di un requisito hardware universale per i suoi nodi. Questo perché una blockchain L2 è intrinsecamente eterogenea: i nodi differenti sono specializzati per svolgere compiti specifici in modo più efficiente. Ad esempio, i L2 comuni utilizzano un nodo sequenziatore speciale per determinare l'ordine delle transazioni. Inoltre, i nodi di tipo prover negli ZK-Rollup spesso si avvalgono di acceleratori specializzati come GPU e FPGA per ridurre il costo della generazione delle prove. MegaETH porta la specializzazione dei nodi a un livello superiore introducendo una nuova classe di nodi chiamati "replica nodes", che rinunciano completamente all'esecuzione delle transazioni, distinguendoli dai tradizionali nodi completi.

Di conseguenza, in MegaETH ci sono quattro ruoli principali: sequenziatori, prover, nodi completi e replica nodes. I nodi sequenziatori sono responsabili dell'ordinamento e dell'esecuzione delle transazioni degli utenti. Tuttavia, MegaETH ha un solo sequenziatore attivo in un dato momento, eliminando il sovraccarico del consenso durante l'esecuzione normale. I nodi di tipo replica ricevono le differenze di stato da questo sequenziatore tramite una rete p2p e applicano direttamente le differenze per aggiornare gli stati locali. È importante notare che non rieseguono le transazioni; invece, validano i blocchi indirettamente utilizzando le prove fornite dai prover. I nodi completi operano come al solito: rieseguono ogni transazione per validare i blocchi. Questo è essenziale per gli utenti avanzati, come gli operatori di bridge e i market maker, per ottenere una finalizzazione rapida, sebbene con requisiti hardware più elevati per tenere il passo con il sequenziatore. Infine, i prover, utilizzando lo schema di validazione senza stato, validano i blocchi in modo asincrono e fuori ordine.

La figura sottostante illustra l'architettura di base di MegaETH e l'interazione tra i suoi principali componenti. Si noti che EigenDA è un componente esterno costruito su EigenLayer.

Un vantaggio chiave della specializzazione dei nodi è la possibilità di stabilire i requisiti hardware per ogni tipo di nodo in modo indipendente. Ad esempio, poiché i nodi sequenziatori gestiscono il lavoro pesante dell'esecuzione, è preferibile eseguirli su server di alta gamma per migliorare le prestazioni. Al contrario, i requisiti hardware per i nodi replica possono rimanere bassi perché la verifica delle prove è computazionalmente poco costosa. Inoltre, sebbene i nodi completi elaborino comunque l'esecuzione, possono sfruttare le informazioni ausiliarie generate dai sequenziatori per rieseguire le transazioni in modo più efficiente. L'implicazione di questa configurazione è profonda: come delineato nel post "Endgame" di Vitalik, la specializzazione dei nodi garantisce una validazione dei blocchi "trustless" e altamente decentralizzata, anche se la produzione dei blocchi diventa più centralizzata.

Questa tabella descrive i requisiti hardware previsti per ogni tipo di nodo in MegaETH:

Omettiamo i nodi prover ZK dalla tabella poiché i loro requisiti hardware dipendono in gran parte dallo stack di prove e possono variare notevolmente tra i diversi fornitori. I costi orari delle varie istanze VM sono tratti da instance-pricing.com. È importante notare che la specializzazione dei nodi ci consente di avere nodi sequenziatori che sono 20 volte più costosi (e 5–10 volte più performanti) rispetto ai validatori medi di Solana, mantenendo i costi dei nodi completi comparabili a quelli dei nodi Ethereum L1.

Progettare una blockchain real-time

Il concetto di specializzazione dei nodi è elegante e potente. Naturalmente, questo solleva la domanda: il segreto dietro MegaETH è semplicemente un sequenziatore centralizzato molto potente? La risposta è no.

Sebbene fare un'analogia con i server centralizzati possa essere un utile modello mentale per comprendere il potenziale di MegaETH, sottovaluta significativamente le complessità di ricerca e ingegneria dietro le quinte. Creare una blockchain real-time implica molto di più che prendere un client di esecuzione Ethereum preconfezionato e aumentare l'hardware dei sequenziatori.

Ad esempio, i nostri esperimenti sulle prestazioni mostrano che anche con un server potente equipaggiato con 512 GB di RAM, Reth può raggiungere solo circa 1000 TPS, che si traducono in circa 100 MGas/s, in una configurazione di sincronizzazione live su blocchi recenti di Ethereum. In questo specifico esperimento, le prestazioni di Reth sono limitate dal sovraccarico di aggiornamento del Merkle Patricia Trie (MPT) in ogni blocco, che è quasi 10 volte più costoso dal punto di vista computazionale rispetto all'esecuzione delle transazioni. Per ulteriori dettagli, rimandiamo i lettori alla nostra presentazione a EthDenver'24: Understanding Ethereum Execution Client Performance.

In sintesi, mentre la specializzazione dei nodi sblocca opportunità significative per miglioramenti delle prestazioni, progettare e implementare una blockchain iper-ottimizzata rimane una sfida ancora irrisolta.

La nostra filosofia del design

Come ogni sistema informatico complesso, una blockchain ha molteplici potenziali colli di bottiglia attraverso vari componenti interagenti. Affrontare un collo di bottiglia isolatamente porta raramente a miglioramenti significativi delle prestazioni end-to-end, perché o (1) non è ancora il fattore limitante più critico, oppure (2) il collo di bottiglia più critico semplicemente si sposta su un altro componente. Troppe volte abbiamo visto progetti concentrarsi sull'ottimizzazione di componenti specifici. Sebbene possano mostrare miglioramenti impressionanti in microbenchmark isolati, questi risultati spesso non si traducono in guadagni di prestazioni end-to-end che beneficiano gli utenti finali.

In MegaETH, abbiamo deciso di applicare un approccio più olistico e rigoroso nel nostro processo di ricerca e sviluppo fin dall'inizio. La nostra filosofia di design può essere riassunta come segue:

Innanzitutto, "misuriamo, poi costruiamo". Cioè, iniziamo sempre conducendo misurazioni approfondite delle prestazioni per identificare i veri problemi dei sistemi esistenti. Sulla base di queste intuizioni, progettiamo quindi nuove tecniche per affrontare tutti i problemi contemporaneamente.

In secondo luogo, ci sforziamo di progettare il sistema per raggiungere i limiti hardware. Invece di fare miglioramenti incrementali sui sistemi esistenti, preferiamo design inediti che si avvicinano ai limiti teorici superiori. Il nostro obiettivo è lasciare poco spazio per ulteriori miglioramenti delle prestazioni nell'infrastruttura cripto, affinché l'industria possa finalmente deviare risorse verso altre sfide che ostacolano l'adozione.

Di seguito, presentiamo una panoramica delle principali sfide nel progettare e implementare una blockchain real-time ad alte prestazioni.

Esecuzione delle transazioni

La figura sottostante illustra il percorso di una transazione utente attraverso il sistema e servirà da riferimento per spiegare le sfide tecniche discusse successivamente.

Inizieremo con il sequenziatore perché è il componente più familiare per molte persone. Il sequenziatore è responsabile dell'ordinamento e dell'esecuzione delle transazioni. L'EVM è spesso accusato di avere prestazioni di esecuzione relativamente basse, il che ha contribuito a numerosi tentativi di sostituirlo con altre macchine virtuali nei L2 di Ethereum.

Tuttavia, questo stereotipo non è affatto vero. Le nostre misurazioni delle prestazioni mostrano che revm può già raggiungere circa 14.000 TPS sui blocchi recenti di Ethereum in una configurazione di sincronizzazione storica. La configurazione della macchina è la stessa dell'esperimento di sincronizzazione live presentato in precedenza.

Mentre 14.000 TPS sono più che sufficienti per la maggior parte dei L2, non sono abbastanza per una blockchain in tempo reale come MegaETH. Le implementazioni tradizionali dell'EVM affrontano tre inefficienze principali:

1) alta latenza nell'accesso allo stato,

2) mancanza di esecuzione parallela e

3) sovraccarico dell'interprete.

Grazie alla specializzazione dei nodi, i nostri nodi sequenziatori sono equipaggiati con abbondante RAM per contenere l'intero stato della blockchain, che attualmente è di circa 100 GB per Ethereum. Questa configurazione accelera significativamente l'accesso allo stato eliminando la latenza di lettura SSD. Ad esempio, nel nostro esperimento di sincronizzazione storica sopra, l'operazione sload rappresenta solo l'8,8% del tempo di esecuzione. Di conseguenza, ci concentreremo sulle altre due sfide di seguito.

L'EVM parallela è diventato un argomento molto discusso di recente, con molti team che si concentrano sul porting dell'algoritmo Block-STM, originariamente implementato per MoveVM, su EVM. Anche se è sicuro affermare che l'EVM parallela sia un problema risolto, c'è un limite: il reale aumento di velocità raggiungibile in produzione è intrinsecamente limitato dal parallelismo disponibile nei carichi di lavoro.

Purtroppo, le nostre misurazioni indicano che il parallelismo mediano nei blocchi recenti di Ethereum è inferiore a 2. Anche se fondessimo artificialmente i blocchi in grandi batch, il parallelismo mediano aumenterebbe solo a 2,75. Esaminando i dati grezzi dell'esperimento, è chiaro che lunghe catene di dipendenze sono prevalenti nei carichi di lavoro odierni di Ethereum. Senza ulteriori tecniche per risolvere i conflitti e aumentare il parallelismo, i benefici dell'EVM parallela rimarranno relativamente limitati.

Come discusso precedentemente nell'esempio di Fibonacci, anche un interprete EVM relativamente veloce come revm è ancora 1–2 ordini di grandezza più lento rispetto all'esecuzione nativa. Rispecchiando questo divario di prestazioni, c'è stato un rinnovato interesse nell'utilizzare la compilazione AOT/JIT per accelerare l'esecuzione EVM su singolo thread, con sforzi concorrenti da parte di più team come revmc, evm-mlir e IL-EVM.

Mentre questi progetti hanno mostrato risultati promettenti su diversi contratti ad alta intensità computazionale, i loro miglioramenti sono piuttosto limitati in un ambiente di produzione. Una delle ragioni è che la maggior parte dei contratti oggi non è molto intensiva in termini di calcolo. Ad esempio, abbiamo profilato il tempo speso su ogni opcode durante la sincronizzazione storica e scoperto che circa il 50% del tempo in revm è dedicato agli opcode "host" e "system", come keccak256, sload e sstore, che sono già implementati in Rust. Di conseguenza, questi opcode non possono beneficiare della compilazione, limitando l'aumento massimo della velocità in produzione a 2x.

Fino ad ora, abbiamo discusso solo delle sfide che sono generiche per tutte le blockchain EVM ad alte prestazioni. I requisiti delle blockchain real-time introducono almeno due sfide aggiuntive. In primo luogo, dobbiamo produrre blocchi in modo consistente ad alta frequenza, come ad esempio ogni 10 millisecondi. In secondo luogo, il nostro motore di esecuzione parallela deve supportare le priorità delle transazioni, consentendo a quelle critiche di essere processate senza ritardi di coda, anche durante i picchi di congestione. Pertanto, nonostante Block-STM sia una buona soluzione generale, non è adatta nel nostro ambiente a bassa latenza.

Sincronizzazione dello stato

La sincronizzazione dello stato è il processo che aggiorna i nodi completi per allinearli al sequenziatore. È uno degli aspetti più complessi nella progettazione di blockchain ad alte prestazioni, eppure è spesso trascurato.

Per capire perché la sincronizzazione dello stato sia complessa, consideriamo transazioni semplici come i trasferimenti ERC-20. Facciamo un calcolo approssimativo per determinare la larghezza di banda richiesta per sincronizzare 100.000 trasferimenti ERC-20 al secondo. Ogni trasferimento ERC-20 modifica tre valori: il saldo del mittente (20 byte per l'indirizzo + 32 byte per il valore) e due slot di archiviazione (64 byte ciascuno) sotto il contratto ERC-20 (20 byte per l'indirizzo). Pertanto, un modo semplice per codificare la differenza di stato costa circa 200 byte. Con 100.000 trasferimenti al secondo, ciò si traduce in un consumo di larghezza di banda di 152,6 Mbps, che già supera il nostro budget di larghezza di banda. In confronto, è persino più costoso che trasmettere i 177 byte dei dati grezzi della transazione direttamente.

Le transazioni più complesse producono differenze di stato più grandi. Ad esempio, uno swap Uniswap modifica 8 slot di archiviazione tra tre contratti, oltre al saldo del mittente: cioè, 64B * 8 + 20B * 3 + 52B = 624B. Con 100.000 swap al secondo, il consumo di larghezza di banda ora è di 476,1 Mbps!

Inoltre, solo perché un nodo completo ha una connessione di rete da 100 Mbps, non significa che possa sincronizzarsi con una piena capacità di utilizzo della rete. Ci sono diverse ragioni per questo. In primo luogo, i fornitori di servizi Internet spesso sovrastimano la larghezza di banda effettivamente sostenibile. In secondo luogo, le applicazioni sullo stesso nodo devono condividere la connessione. In terzo luogo, deve essere riservato uno spazio sufficiente per consentire ai nuovi nodi completi di avviarsi e unirsi alla rete. Se i nodi completi funzionassero sempre al 100% della capacità di rete, i nodi appena entrati non potrebbero mai raggiungere la punta. Infine, i protocolli di rete peer-to-peer inevitabilmente introducono i loro sovraccarichi.

Quindi, quanta larghezza di banda possiamo allocare comodamente per la sincronizzazione dello stato? Supponiamo che la larghezza di banda media sostenibile sia di 75 Mbps, e mettiamo da parte i due terzi per altre applicazioni e per l'avvio di nuovi nodi. Questo ci lascia con 25 Mbps. In questo caso, per sincronizzare 100.000 swap Uniswap al secondo, sarebbe necessaria una compressione dei dati dello stato di 19 volte!

Aggiornamento della root dello stato

La maggior parte delle blockchain, inclusa Ethereum, utilizza una struttura dati ad albero autenticata come l'MPT per memorizzare i propri stati dopo ogni blocco. L'impegno, noto come root dello stato, è essenziale per fornire le prove di archiviazione ai client leggeri. Di conseguenza, anche con la specializzazione dei nodi, i nodi completi sono ancora necessari per mantenere la root dello stato, proprio come i nodi sequenziatori.

Come discusso in precedenza, l'aggiornamento della root dello stato in Reth è attualmente quasi 10 volte più costoso dell'esecuzione delle transazioni, poiché questo processo è estremamente intensivo in termini di input/output (IO). Ad esempio, la figura sottostante illustra il modello di IO coinvolto nell'aggiornamento di un nodo lead in un MPT binario.

Nell'MPT, ogni leaf memorizza una coppia chiave-valore che fa parte dello stato della blockchain, mentre ogni nodo interno memorizza un hash intermedio che impegna il suo sottoalbero sottostante e contiene puntatori ai suoi nodi figli. Per aggiornare la radice dello stato dopo aver modificato una leaf, è necessario aggiornare anche tutti i nodi interni lungo il percorso dalla radice a quella leaf, il che richiede anche la lettura dei nodi figli per ricalcolare gli hash. Ad esempio, l'aggiornamento della leaf a nella figura sopra implica la lettura di 3 nodi e l'aggiornamento di 4 nodi in totale. Si noti che un nodo interno deve essere letto prima di poter essere aggiornato; altrimenti, è impossibile determinare come recuperare i suoi nodi figli.

In generale, aggiornare una singola coppia chiave-valore in un MPT k-ary con n leaf richiede la lettura e la scrittura di O(k log_k n) e O(log_k n) nodi, rispettivamente. Per un MPT binario con 16 miliardi di chiavi (ovvero 1 TB di stato della blockchain), questo si traduce in circa 68 operazioni di lettura e 34 operazioni di scrittura. Fortunatamente, di solito possiamo memorizzare nella cache i primi 24 livelli di un MPT binario, quindi solo le ultime 20 operazioni di lettura e 10 operazioni di scrittura possono comportare operazioni di I/O casuali su disco.

Per comprendere meglio questa sfida, rivediamo l'esempio di 100.000 trasferimenti ERC-20 al secondo. Poiché ogni trasferimento ERC-20 modifica tre valori, la trie dello stato deve supportare l'aggiornamento di 300.000 chiavi al secondo. Per un MPT binario semplice, questo si tradurrebbe in circa 6 milioni di letture di database non memorizzate nella cache. Anche se supponiamo che ciascuna di queste letture di database possa essere servita con una singola operazione I/O su disco, 6 milioni di IOPS superano di gran lunga le capacità di qualsiasi SSD consumer oggi disponibile — e questo calcolo non tiene nemmeno conto delle operazioni di scrittura.

Una strategia di ottimizzazione comune per ridurre le operazioni di I/O su disco è quella di raggruppare più nodi della trie in un sottoalbero e memorizzarli in una singola pagina disco da 4 KB. Ad esempio, NOMT inserisce ogni sottoalbero binario senza radice di profondità 6 in una pagina disco. Idealmente, ciò ridurrebbe il numero di letture di database non memorizzate nella cache per chiave aggiornata da 20 a 2, risultando in circa 600.000 IOPS. Tuttavia, è importante notare che la differenza tra un calcolo ottimistico e la performance di una reale implementazione può essere sostanziale a causa dei sovraccarichi del software. Secondo il benchmark di Thrum, un NOMT con 134 milioni di chiavi può attualmente gestire fino a 50.000 aggiornamenti di leaf al secondo. Sebbene questo rappresenti un miglioramento significativo rispetto alle implementazioni attuali della trie dello stato, è ancora 6 volte inferiore alla nostra throughput desiderata, operando su uno stato della blockchain che è 128 volte più piccolo dell'esempio sopra.

Limite di gas del blocco

Finora, abbiamo discusso delle sfide per accelerare le varie operazioni eseguite dai nodi della blockchain. Tuttavia, c'è una controindicazione: anche se qualcuno riesce a sviluppare una tecnica brillante che velocizza un compito specifico di 10 volte nella maggior parte dei casi, non significa necessariamente che la blockchain possa funzionare più velocemente.

Il motivo è che la velocità massima di una blockchain è limitata da un limite artificiale noto come "limite di gas del blocco", che è integrato nel consenso. Il limite di gas del blocco definisce la quantità massima di gas che può essere consumata all'interno di un singolo blocco. Insieme al tempo del blocco, il limite di gas del blocco agisce come un meccanismo di limitazione per garantire che ogni nodo nel sistema possa tenere il passo con il resto della rete, purché soddisfi i requisiti hardware minimi.

Il limite di gas del blocco è essenziale per garantire la sicurezza e l'affidabilità di una blockchain. Una regola pratica per impostare il limite di gas del blocco è che deve garantire che qualsiasi blocco all'interno di questo limite possa essere processato affidabilmente nel tempo del blocco. Non rispettare questo criterio esporrebbe la rete a vulnerabilità da attacchi maligni. In altre parole, il limite di gas del blocco deve essere scelto in modo conservativo per tenere conto degli scenari peggiori.

Ad esempio, ricorda che il miglioramento pratico di una EVM parallela dipende fortemente dal carico di lavoro. Sebbene sia possibile ottenere un miglioramento medio di 2 volte sui carichi di lavoro storici, una parte significativa dei blocchi contiene lunghe catene di dipendenza e quindi sperimenta miglioramenti minimi. Di conseguenza, senza un meccanismo di pricing del gas multidimensionale, come il mercato locale delle commissioni di Solana, che possa prezzare gli accessi agli stati contesi più costosi, non è possibile aumentare il limite di gas del blocco basandosi sul miglioramento medio ottenuto da una EVM parallela, per non parlare del miglioramento massimo.

Allo stesso modo, i miglioramenti dei contratti JIT-compiled dipendono in gran parte dalla natura dei contratti. Mentre i contratti computazionalmente intensivi possono ottenere miglioramenti da 1 a 2 ordini di grandezza, la maggior parte dei contratti oggi ottiene solo miglioramenti moderati. Inoltre, la compilazione JIT introduce sovraccarichi che non sono catturati dal modello di gas attuale. Ad esempio, la compilazione stessa consuma cicli CPU, il codice nativo risultante occupa memoria o spazio su disco, ecc. Pertanto, prima che il modello di gas venga rielaborato per (1) tenere conto dei sovraccarichi di compilazione, e (2) rivedere correttamente i prezzi degli opcode che non beneficiano della compilazione, non possiamo aumentare in modo aggressivo il limite di gas del blocco per abilitare applicazioni computazionalmente intensive.

Infrastruttura di supporto

Infine, gli utenti non interagiscono direttamente con i nodi sequenziatori, e la maggior parte non gestisce nodi completi a casa. Invece, gli utenti inviano transazioni a nodi RPC di terze parti e si affidano a frontend web di dApp o esploratori di blockchain, come etherscan.io, per confermare i risultati delle transazioni.

Pertanto, l'esperienza utente effettiva di una blockchain dipende in gran parte dalla sua infrastruttura di supporto, come i nodi RPC e gli indicizzatori. Non importa quanto velocemente una blockchain in tempo reale funzioni, non avrà importanza se i nodi RPC non possono gestire in modo efficiente grandi volumi di richieste di lettura durante i picchi, propagare rapidamente le transazioni ai nodi sequenziatori, o se gli indicizzatori non riescono ad aggiornare rapidamente le visualizzazioni delle applicazioni per tenere il passo con la blockchain.

Scalare la blockchain con un approccio principled

Speriamo che ora sia chiaro che le blockchain sono davvero sistemi complessi con molte parti in movimento, e migliorare le prestazioni di una blockchain richiede più di tecniche isolate come EVM parallela o compilazione JIT. Tutte le blockchain L1 ad alte prestazioni di successo, come Solana e Aptos, hanno intrapreso impressionanti sforzi ingegneristici in quasi ogni aspetto dei loro sistemi.

Per questo motivo, MegaETH si impegna fin dall'inizio a un approccio R&D olistico e basato su principi. Conducendo un'analisi approfondita delle prestazioni fin dall'inizio, garantiamo che ci concentriamo sempre sulla risoluzione dei problemi che apporteranno reali miglioramenti agli utenti. Durante il percorso, siamo entusiasti di renderci conto che, nonostante tutte le sfide discusse prima, abbiamo qualcosa di interessante da offrire. Sebbene le soluzioni specifiche siano al di fuori dell'ambito di questo post, non vediamo l'ora di trattarle in modo più dettagliato in futuro.

Portare la performance real-time a miliardi di utenti

Le blockchain real-time sfumeranno la linea tra i server Web2 e le blockchain. Con MegaETH, gli utenti finali vivranno prestazioni in tempo reale senza precedenti, mentre gli sviluppatori potranno esplorare le loro idee più ambiziose senza limitazioni. Dopo un decennio di sperimentazioni, finalmente possiamo avvicinarci alle applicazioni su larga scala del Web2 on-chain.

Siamo profondamente grati ai nostri sostenitori finora e incredibilmente entusiasti di condividere ulteriori dettagli su ciò che abbiamo da offrire.

Alla prossima.