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:
- 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.
- 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.
- 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.
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:
- 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.
- 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 💀
- 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:
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.
Sequencing
There are two recurring concerns with a single sequencer design:
- Single point of failure for security
- 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:
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.
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.
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.
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.
- Ensure that our prover is compatible with our EVM execution environment.
- 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.
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!
