Dual-Block-Architektur

Der gesamte HyperEVM-Durchsatz teilt sich auf kleine Blöcke, die mit hoher Frequenz erzeugt werden, und große Blöcke, die mit geringerer Frequenz erzeugt werden, auf.

Die primäre Motivation hinter der Dual-Block-Architektur besteht darin, Blockgeschwindigkeit und Blockgröße bei der Zuweisung von Durchsatzverbesserungen zu entkoppeln. Nutzer wünschen sich schnellere Blöcke für kürzere Bestätigungszeiten. Builder wünschen sich größere Blöcke, um größere Transaktionen wie komplexere Contract-Deployments aufzunehmen. Statt eines erzwungenen Zielkonflikts ermöglicht das Dual-Block-System eine gleichzeitige Verbesserung auf beiden Achsen.

Der „Mempool" des HyperEVM ist in Bezug auf die übergeordnete L1-Ausführung nach wie vor On-Chain-Zustand, ist aber in zwei unabhängige Mempools aufgeteilt, die Transaktionen für die beiden Blocktypen liefern. Die beiden Blocktypen werden mit einer eindeutigen, aufsteigenden Folge von EVM-Blocknummern verschachtelt. Die On-Chain-Mempool-Implementierung akzeptiert für jede Adresse nur die nächsten 8 Nonces. Transaktionen, die älter als 1 Tag im Mempool sind, werden entfernt.

Die anfängliche Konfiguration ist konservativ gewählt, und es wird erwartet, dass der Durchsatz mit aufeinanderfolgenden technischen Upgrades steigt. Die Blockdauer schneller Blöcke ist auf 1 Sekunde bei einem Gas-Limit von 3M festgelegt. Die Blockdauer langsamer Blöcke ist auf 1 Minute bei einem Gas-Limit von 30M festgelegt.

Genauer gesagt bedeutet in den obigen Definitionen Blockdauer von x, dass der erste L1-Block für jeden Wert von l1_block_time % x einen EVM-Block erzeugt.

Entwickler können größere Contracts wie folgt deployen:

1. Senden Sie die Aktion {"type": "evmUserModify", "usingBigBlocks": true}, um HyperEVM-Transaktionen in große statt in kleine Blöcke zu leiten. Beachten Sie, dass dieses Nutzerzustands-Flag auf Ebene des HyperCore-Nutzers gesetzt wird und zum Adressieren kleiner Blöcke wieder zurückgesetzt werden muss. Wie jede Aktion erfordert dies, dass ein bestehender Core-Nutzer sie sendet. Wie jede EOA kann die Deployer-Adresse in einen Core-Nutzer umgewandelt werden, indem sie ein Core-Asset wie USDC empfängt.
2. Optional können Sie die JSON-RPC-Methode bigBlockGasPrice anstelle von gasPrice verwenden, um die Basis-Gas-Gebühr für den nächsten großen Block zu schätzen.