Architettura a doppio blocco

La produttività totale di HyperEVM è suddivisa tra blocchi piccoli prodotti a una frequenza elevata e blocchi grandi prodotti a una frequenza inferiore.

La motivazione principale alla base dell'architettura a doppio blocco è separare la velocità dei blocchi dalle loro dimensioni quando si distribuiscono i miglioramenti della produttività. Gli utenti desiderano blocchi più veloci per ridurre il tempo di conferma. I builder desiderano blocchi più grandi per includere transazioni di maggiori dimensioni, come deployment di contratti più complessi. Invece di un compromesso forzato, il sistema a doppio blocco consentirà un miglioramento simultaneo su entrambi gli assi.

Il "mempool" di HyperEVM è ancora uno stato on-chain rispetto all'esecuzione L1 complessiva, ma è suddiviso in due mempool indipendenti che alimentano di transazioni i due tipi di blocco. I due tipi di blocco sono intervallati secondo un'unica sequenza crescente di numeri di blocco EVM. L'implementazione on-chain del mempool accetta solo i successivi 8 nonce per ciascun indirizzo. Le transazioni presenti nel mempool da più di 1 giorno vengono eliminate.

La configurazione iniziale è impostata in modo conservativo e si prevede che la produttività aumenti con i successivi aggiornamenti tecnici. La durata dei blocchi veloci è impostata a 1 secondo con un limite di gas di 3M. La durata dei blocchi lenti è impostata a 1 minuto con un limite di gas di 30M.

Più precisamente, nelle definizioni sopra riportate, per durata del blocco pari a x si intende che il primo blocco L1 per ciascun valore di l1_block_time % x produce un blocco EVM.

Gli sviluppatori possono eseguire il deployment di contratti di maggiori dimensioni come segue:

1. Inviare l'azione {"type": "evmUserModify", "usingBigBlocks": true} per indirizzare le transazioni HyperEVM ai blocchi grandi anziché ai blocchi piccoli. Si noti che questo flag di stato dell'utente è impostato a livello di utente HyperCore e deve essere nuovamente disattivato per tornare a utilizzare i blocchi piccoli. Come qualsiasi azione, richiede l'invio da parte di un utente Core esistente. Come qualsiasi EOA, l'indirizzo del deployer può essere convertito in un utente Core ricevendo un asset Core come USDC.
2. Facoltativamente, utilizzare il metodo JSON-RPC bigBlockGasPrice al posto di gasPrice per stimare la commissione gas base sul blocco grande successivo.