ENDGAME: Come abbiamo raggiunto blocchi a 10ms
La testnet è qui. Discutiamo in modo più approfondito una sfumatura tecnica del nostro sistema: i mini-blocchi. Il loro unico scopo è spingere al limite le prestazioni di MegaETH e giocare un ruolo essenziale nel realizzare una blockchain in tempo reale. Tuttavia, è importante comprendere il come e il perché – parliamone.
Prima di tutto, alcuni termini e definizioni.
GLOSSARIO
- Blocchi EVM
Per il resto dell’articolo, questo termine indicherà i blocchi “tradizionali”, retrocompatibili all’interno dell’ecosistema EVM più ampio.
Essi mantengono l’intero peso dei metadati, consentendo a cose come RPC, strumenti per sviluppatori e block-explorer di integrarsi con MegaETH senza dover ricostruire completamente il loro sistema.
Questi blocchi vengono prodotti ad intervalli di 1 secondo.
- Mini-Blocchi
Il nostro termine per indicare i blocchi leggeri (in termini di metadati) e prodotti con maggiore frequenza da MegaETH.
Questi blocchi vengono generati in parallelo rispetto ai blocchi EVM e offrono le stesse garanzie di inclusione, con l’unica differenza di un intervallo di propagazione notevolmente ridotto al resto della rete.
Sono prodotti ad intervalli di 10ms, con l’ambizione di ridurre questo intervallo a 1ms.
- Tempi di Blocco
Il tempo che intercorre tra blocchi della stessa classificazione (EVM con EVM o mini con mini).
Poiché abbiamo progettato il nostro sistema per offrire le stesse garanzie per i mini-blocchi come per i blocchi EVM, miriamo a un futuro in cui i “tempi di blocco” siano espressamente riferiti ai mini-blocchi, poiché l’intera catena può essere interpretata esclusivamente dalla loro visione.
VISUALIZZATO
Un confronto visivo delle due visioni della chain che MegaETH offre:
Blocchi EVM per la retrocompatibilità e mini-blocchi per aggiornamenti in tempo reale e leggeri dello stato della chain, con lo stesso livello di garanzie.
CARATTERISTICHE CHIAVE, CONFRONTI
Abbiamo coperto le definizioni, fornito alcuni dettagli ad alto livello e aggiunto una visualizzazione per agevolare la formazione di modelli mentali.
Adesso, parliamo dei confronti tra ecosistemi e di quali proprietà vengano (o non vengano) preservate nella nostra implementazione.
CONFRONTI TRA ECOSISTEMI
- Flashblocks di Base (link)
Recentemente implementati sulla testnet Sepolia, questi utilizzano TEE per creare sub-blocchi/pre-conferme delle transazioni a intervalli di 200ms all’interno dei tempi di blocco di 2 secondi.
Design multi-view di MegaETH rispetto all’implementazione dei flashblock di Base.
Entrambi i sistemi beneficeranno della protezione da revert dei loro blocchi più piccoli, mentre i Flashblocks introducono alcune assunzioni di fiducia nei confronti dei fornitori di TEE.
- Shreds di Solana (link)
Design multi-view di MegaETH rispetto all’architettura di shredding di Solana.
Gli shreds, recentemente messi in luce a seguito dell’implementazione dei Flashblock di Base, sono simili ai mini-blocchi per frequenza (~15ms), ma con una differenza fondamentale: Solana adotta il consenso.
Con i requisiti di consenso sorge il rischio che vengano prodotti blocchi non confermati/garantiti, cosa che si estende anche agli shreds. Questo significa che in alcuni casi uno shred potrebbe essere propagato prima che il leader completi il suo blocco, e se non lo fa in tempo, lo shred diventa invalido e deve essere scartato.
Questo rappresenta una piccola percentuale del totale nel paradigma attuale di Solana, ma è un sottoprodotto di un protocollo che prevede il consenso.
- Architettura a Doppio Blocco di Hyperliquid (link)
Questa soluzione è per lo più un equivalente concettuale in termini di risultato desiderato, sebbene implementata in modo diverso.
Confronto visivo tra l’architettura a doppio blocco di Hyperliquid e i mini-blocchi e blocchi EVM.
L’obiettivo del loro design è creare una catena in grado di (a) elaborare transazioni rapidamente e (b) gestire transazioni di grandi dimensioni o pesanti.
La loro soluzione consiste nell’avere due mempool separate per transazioni di dimensioni differenti, processarli in blocchi di dimensioni diverse e poi intercalarli nella catena.
Le ambizioni di MegaETH sono le stesse, ma raggiungiamo questo risultato senza la necessità di segregare le transazioni e intercalarle, grazie a (a) un design di esecuzione parallela “execute-then-order” e (b) l’utilizzo della specializzazione dei nodi per eliminare praticamente il vincolo computazionale/gas per gli sviluppatori.
La combinazione di questi elementi ci permette di ottenere tempi di blocco costanti di 10ms per i mini-blocchi su transazioni di qualsiasi complessità e dimensione, senza la complessità aggiuntiva della segregazione tra transazioni e blocchi.
CARATTERISTICHE CHIAVE
- Garanzie di Rollback
Già menzionato, ma ribadito qui: i mini-blocchi sono cittadini di prima classe all’interno di MegaETH e godono di tutte le garanzie condivise dai blocchi EVM.
Un rollback su un qualsiasi mini-blocco è considerato grave quanto un rollback su un blocco EVM e comporterebbe lo stesso rischio di slashing.
Per realizzare la visione di creare la prima blockchain in tempo reale, dobbiamo essere non solo performanti, ma anche coerenti e affidabili.
Il recupero dei dati e la protezione da revert sono proprietà di grande valore nel nostro ecosistema.
- Impostazione dei Parametri
L’implementazione di elementi come l’EIP-1559 avviene a livello di blocco EVM per preservare l’equivalenza con l’EVM, il che significa che l’attuale Base fee (0.0025 Gwei), la dimensione del blocco (2G gas) e il Target (1G gas) si riferiscono tutti all’intervallo di 1 secondo.
- Produzione Elastico dei Blocchi
L’attuale configurazione è ottimizzata per prestazioni massime e riduzione degli sprechi.
Ciò significa che, invece di creare blocchi vuoti a intervalli prestabiliti, né i mini-blocchi né i blocchi EVM vengono prodotti se non sono presenti transazioni, rendendo i tempi di blocco elastici e basati sulla domanda.
Questo è un dettaglio implementativo che potrà essere modificato in futuro se ritenuto utile, ma continueremo a privilegiare prestazioni ed efficienza.
- Compatibilità con Ethereum JSON RPC
Abbiamo migliorato diversi endpoint per consentire l’ingestione dei mini-blocchi, mantenendo al contempo la retrocompatibilità con il tradizionale Ethereum JSON RPC, con l’obiettivo di continuare a potenziare le funzionalità esistenti e di lanciare nuove API basate sui primi feedback degli sviluppatori.
- Differenze nei Metadati EVM/Mini
Presto arriveranno documenti per sviluppatori™️.
FIN
Se quanto sopra ha catturato la tua attenzione, tieni d’occhio i prossimi documenti per sviluppatori e unisciti al programma per sviluppatori per scoprire cosa il tempo reale può fare per la tua app.
Il futuro sarà a RABBIT SPEED e alimentato dai MINI-BLOCCHI.