Hunters on Chain is on Immutable!
Play Now
Home
Arrow icon
Blog
Arrow icon
Immutable zkEVM
12/21/2023

Under the Hood: Immutable zkEVM

Immutable logo with text "Under the hood: Immutable zkEVM"
Icon with concentric circles
TL;DR

With the launch of Immutable zkEVM Mainnet rapidly approaching, we want to ensure game studios, developers, partners, and the broader community have an opportunity to understand what we’re building.

We know people are eager to understand how Immutable zkEVM solves some of the most challenging technical problems in being fit-for-purpose and scalable to support the growing game industry demand. This blog post addresses the most frequently asked questions about Immutable zkEVM’s technical architecture.

What problem is the Immutable zkEVM blockchain solving?

We spend a lot of time talking with game studios that are building web3 games; there are three problems that we frequently hear about existing blockchains:

  1. Performance - Almost all partially and fully on-chain games need to operate in high bandwidth, high frequency, and low latency environments to deliver the best gaming experience. It has become clear that chains using 10-second block times with 15+ minutes finality, limited bandwidth/blockspace, and high transaction costs won’t be suitable for integration into core game loops. It’s essential for games to achieve high levels of scale without compromising on the stability and security game studios expect from a blockchain, two less talked about but equally important properties.
  2. Regulations - Game studios want to comply with regulations, protect their gamers, and not get distracted from developing their games. Doing all three is hard, so there is a strong need for a partner who will make complying with all relevant regulations as easy as possible. 
  3. Developer experience - Ease and maturity are also crucial for game studios. This is why a battle-tested, compatible, and widely adopted technology stack with strong network effects based on the EVM is preferred over a new experimental VM.

When you combine all these requirements, none of the existing blockchain solutions in the market truly satisfy a game studio's needs. This is why Immutable built Immutable zkEVM.

An architecture that optimizes for gaming

At a high level, Immutable zkEVM comprises an EVM-equivalent blockchain client, separated into an execution and consensus client, and a zero-knowledge proving system with an integrated native bridge. Each component will be expanded on in the following sections. The native bridge is used to secure communication and bridge funds between Immutable zkEVM and Ethereum. Figure 1 depicts the high-level components used in Immutable zkEVM.

Figure 1. High-level architecture

Execution and Consensus Client

For the Mainnet launch, Immutable zkEVM will operate as a Clique-based single sequencer running on a customized Go-ethereum client with single-block finality at a 2s block time. Our main priority for the launch was our chain's stability and security (safety and consistency). To that end, we’ve made the following design decisions:

  1. Decision #1 - Build on the shoulders of Ethereum (EVM equivalence): Launch with Clique with minor changes to the Go-ethereum RPC layer but zero changes to the EVM/execution layer to benefit from active upstream modifications and fixes from the latest fork on Ethereum and retain EVM equivalence.
  2. Decision #2 - Single-block finality: Single-block finality means that once the chain's state is finalized every 2 seconds, there is no chance that the chain will fork or undergo a reorg; in simple terms, this is to avoid creating two simultaneous futures or re-writing history. The safety and consistency of chain state for games operating at high ticks are simply non-negotiable. Imagine winning a quest and claiming your reward, and 5s later, you no longer own your reward; worse yet, it’s now owned by another player 💀
  3. Decision #3 - Single sequencer for now: The single sequencer is underpinned by resilient and redundant infrastructure. Invariants that prevent forking or reorgs are built into client code and infrastructure to guarantee that blockchain data observed and read by external systems and users through the RPC nodes will not change.

Additionally, we have integrated with third-party RPC providers like QuickNode to scale our read loads, especially on read-heavy endpoints like `debug/trace.`

RPC-level controls 

Immutable zkEVM has put two additional RPC-level controls in place:

  1. Transaction blocklist
    1. This is necessary for game studios to comply with international regulations. The list would include sanctioned addresses and potential contracts performing malicious / fraudulent activity harming the rest of the ecosystem.
  2. Deployer allowlist
    1. This measure limits which addresses can deploy on Immutable zkEVM. The allowlist will enable us to establish tighter feedback loops and direct lines of communication with attributable studios and coordinate launches, plan upgrades, or even debug contract issues/bugs causing widespread negative impacts on gamers. We do this as a quality control measure to protect our ecosystem of games from malicious and poorly designed contracts and to conserve chain bandwidth from unattributable non-gaming and spam activity. Additionally, the allowlist is essential to ensure that only a royalty-enforcing trading venue, the Immutable Seaport contract, is available for trading ERC721/1155s.
    2. The initial set of addresses allowed to be deployers on Mainnet will be limited to Immutable, select games, and ecosystem partners. We encourage everyone else to continue taking advantage of our Immutable zkEVM Testnet as any other EVM chain, as we will open up our allowlist soon to allow for a broader ecosystem and developer engagement. For those not on the allowlist, addresses can still deploy either through our Hub’s contract deployment UI or by calling `deployPreset(*)` on our contract factory, which is initialized with an audited and curated set of Immutable presets such as a royalty-enforcing ERC721, and more making it easier to build your game on safer foundations.

Chain configuration

The following table outlines Immutable zkEVM’s standard configuration; each parameter was selected to ensure our chain is fit-for-purpose for games.

Parameter (Developer) Description Value Importance for gaming
Block period The minimum time for transactions to be sealed into a block and considered final. 2 seconds As mentioned above, most games we talk to operate at high-frequency tick rates; a 2s block period and finality time are necessary to enable good gameplay.
Block gas limit The maximum amount of gas available in a block 30M This minimum bandwidth is necessary to facilitate in-game economies, gameplay, and trading. For the more advanced reader, this is equivalent to Ethereum’s entire block space capacity multiplied by 6 and dedicated to Immutable games.
Considering the block gas limit with the block time, our chain’s theoretical bandwidth is 30M gas per 2 seconds (or 15M gas per second.) If we take a regular native transfer that costs 21K gas, we can accommodate up to approximately 714 native transfers per second.
Block gas target Deviation from this target will adjust the base fee in the subsequent block. 15M This is an initial heuristic as we must observe the severe short-term gas spikes that games are willing to accept. ½ is reasonably conservative, and we’ll increase it over time as we see the network functioning stably.
Base fee rate of change The maximum rate to adjust the base fee, increasing it when the network is congested and decreasing it when it's under-utilized, to maintain an equilibrium of block space demand i.e. the Block Gas Target. See EIP-1559. 2% This parameter aims to smooth severe gas price fluctuations, especially during peak demands such as a game’s primary sale launch. We want to minimize the impact on neighboring games on Immutable zkEVM.
Price limit (minimum $IMX price per gas unit) The minimum price per gas unit. This enforces a minimum for the GasTipCap, and GasFeeCap (GasFeeCap must be >= GasTipCap) minimum price per gas unit, but the extractable or effective tip can be less than this number. E.g. if the baseFee is 7 and the GasTipCap/GasFeeCap is 1000, then the effective tip is GasFeeCap - baseFee = 993, less than the GasTipCap. 10 gwei-IMX Chain block capacity is a scarce resource; this price limit ensures that there will be a floor / minimum $IMX price per gas unit to prevent low-valued spam.
Note that this value will change depending on the $IMX price to ensure the chain remains cheap enough for games to transact while still being relevant to protect the chain from low-valued spam.

Sequencing

There are two recurring concerns with a single sequencer design:

  1. Single point of failure for security
  2. Availability or liveness of block production when the block-producing node experiences downtime due to a misconfiguration, network, or hardware failure. 

For these reasons, we see operating as a single sequencer as a temporary state. Our next priority will be to improve the resiliency of our system while maintaining the guarantees of single-block finality. 

Consensus

In blockchain, consensus is the cornerstone that transforms decentralized chaos into trust and reliability.

Eliminating the single point of failure for security is, first and foremost, the main reason for introducing a consensus algorithm. If an adversary compromises the single sequencer and the associated signing key, they can modify the chain state.

Secondly, one standard solution you see across all other rollups to solve the problem of censorship, availability, or liveness of transaction inclusion or block production is introducing a forced exit mechanism through an L1 smart contract. This provides an anti-censorship fallback route for users to force include their transaction, e.g. a withdrawal from the rollup, by making a smart contract call. This is easier said than done; to generate such a transaction, a user must provide proof of ownership over their funds by generating a Merkle Proof, pay a large amount of L1 gas for spam prevention, and wait anywhere from an additional 24 hours to an entire week to ensure the single sequencer has enough time to process the transaction and to disincentivize forced exit as a standard transaction submitting route. Expecting average users to perform this complex set of tasks is unacceptable! Additionally, gamers are used to a simple and instant Web2 experience. A reliable and secure consensus algorithm will provide these safety and liveness benefits seamlessly without requiring the user to perform additional actions.

Another problem that Immutable will soon face is allowing a portion of validators operated by third parties like QuickNode and potentially other large game publishers. How do we ensure that some components run by third parties don’t fail in this distributed system and produce inconsistent information, leading to overall chain unreliability and failure? This is the exact definition of a set of problems known as Byzantine faults

To that end, Immutable will be building BFT (Byzantine Fault Tolerance, unsurprisingly) into Immutable zkEVM. Specifically, we will operate a separate BFT consensus client similar to the Beacon Client used for Ethereum consensus. This allows us to avoid:

  • Safety issues: No known issues exist where different nodes can end up with different states.
  • Liveness issues: The blockchain creates blocks assuming a threshold number of validator nodes can reach consensus. That is:
    • Liveness: Removal of a single point of failure where the protocol can get into a state where no block can be produced.
    • Responsiveness: Removal of a single point of failure where the protocol can stall for a significant period (a multitude of block times).

Additionally, we’ll be overlaying our BFT algorithm with Proof of Stake (PoS) to allow token holders to delegate their stake to one of our validators and provide a mechanism to reward and slash/penalize malicious validators. More information about our PoSBFT design will be in a separate blog.

Figure 2. PoSBFT
Bridge

The native bridge can be decomposed into an application and general message-passing component, a 2-layer OSI model. The application layer involves all logic associated with depositing, withdrawing, and rate-limiting ERC20s. In the future, we can extend this to support ERC721s (NFTs) and the bridging of native ERC20s / 721s on L2. The general message-passing layer is built on Axelar’s permissionless PoS network to secure the sending and receiving of arbitrary messages, and function calls while delivering a one-click user experience. 

Design decisions:

  • Security: By having Immutable manage the application layer and Axelar the general message-passing layer, Immutable can retain break-glass responsibility to pause the bridge in the case of a suspiciously sizeable monetary outflow by a malicious actor. Additionally, we’ve introduced a flow rate functionality that will automatically kick in whenever an unsupported currency is withdrawn or when either a single withdrawal or the outflow rate exceeds the configurable limit. 
  • Upgradability: A multi-sig currently secures our upgrade mechanism. However, we plan to introduce a seven-day upgrade delay as the system matures to ensure the upgrade mechanism cannot intervene in real-time disputes, and a user can still choose to eject from the platform if they disagree with the upgrade. Additionally, we’re looking to further diversify our signatory set as risk mitigation.
  • Modularity: We’ve adopted an adaptor to decouple the application from the message-passing layer. This allows us to introduce new message-passing protocols, such as one based on zk proofs, without fragmenting liquidity. 

Figure 3. Bridge adaptor design
Prover

Our next priority will be to make sure that in the scenario when a supermajority of validators on our chain is compromised, the worst that could happen is disruption on the rollup, causing L2 blocks to stop being produced. To achieve this, we need to introduce a prover to ensure the state (where we are) and execution (how we get there) correctness of our system are backed by cryptographically verifiable and scalable mathematical proofs. 

Figure 4. Client to Prover integration

As part of our strategy to take the training wheels off our rollup, we’ll start by generating and verifying shadow proofs similar to zkSync’s Boojum setup with actual production data. We must be confident about two things before relying on zk proofs on Mainnet. 

  1. Ensure that our prover is compatible with our EVM execution environment. 
  2. Can handle a wide variety of real-world activities. 

As zk proofs continue their ongoing innovation to unlock greater economies of scale, we'll gradually increase our bridge’s reliance on zk proofs to secure messages by relying on zk proofs as the authority to accept or reject which state roots get accepted by the root contract (see Figure 5 for a depiction of this integration and peripheral contracts). One immediate benefit to doing so is to enable fast and secure bridging across our chains.

The prover will protect us against disastrous scenarios where the super majority of validators are either incorrectly configured, have a software client-level bug, or become malicious. It’ll prevent a loss of funds since cryptographic proof must back any message. To exploit the system when we have a prover,  an attacker must exploit the execution client, consensus client, and now the prover and verifier contracts. This is an intractable problem that will greatly raise the security bar. 

Currently, we’re considering two different Polygon zkEVM provers, Zero (Type 1) when plonky3 is production-ready and Hermez (Type 2/3) as a backup for Immutable’s proving system. For zkEVM type classification, see Vitalik’s post. Ultimately, the decision will be based on compatibility with our EVM execution environment and cost efficiency.

In the future, to provide better trust-minimized interoperability across Immutable-supported chains, we’re also considering verification of consensus to prove that for every finalized block, a valid signature exists from a supermajority of validators currently active on our network.

Figure 5. Prover integration with Bridge

What’s next?!

And that’s a wrap! To recap, I hope this article has convinced you of how and why Immutable zkEVM should be the primary choice of a chain for any game. In the coming year, the central themes for Immutable zkEVM are PoSBFT consensus, securing our chain and bridge with a ZK prover, and some exciting innovations we can’t reveal yet. Each will have its own technical deep dive blog.

In the meantime, please try out our Immutable zkEVM Testnet (network URL/chain ID available on our developer docs) and reach out on Discord if you have any additional questions. We will be publicly launching our Mainnet shortly, so stay tuned!

Immutable zkEVM
Join the Immutable Newsletter

Be the first to receive Immutable updates, announcements and more.

$IMX Token Address
The official $IMX token address is: