Table of Contents

Introduction

Ethereum's future is rollup-centric. This means breaking with the current paradigm of isolated EVM chains to infrastructure that is focused on an ecosystem of interconnected zkEVMs/zkVMs, (which we name Hyperchains). This ecosystem will be grounded on Ethereum, requiring the appropriate L1 smart contracts. Here we outline our ZK Stack approach for these contracts, their interfaces, the needed changes to the existing architecture, as well as future features to be implemented.

If you want to know more about Hyperchains, check this blog post, or go through our docs.

High-level design

We want to create a system where:

• Hyperchains should be launched permissionlessly within the ecosystem.
• Hyperbridges should enable unified liquidity for assets across the ecosystem.
• Multi-chain smart contracts need to be easy to develop, which means easy access to traditional bridges, and other supporting architecture.

Hyperchains have specific trust requirements - they need to satisfy certain common standards so that they can trust each other. This means a single set of L1 smart contracts has to manage the proof verification for all hyperchains, and if the proof system is upgraded, all chains have to be upgraded together. New chains will be able to be launched permissionlessly in the ecosystem according to this shared standard.

To allow unified liquidity each L1 asset (ETH, ERC20, NFTs) will have a single bridge contract on L1 for the whole ecosystem. These shared bridges will allow users to deposit, withdraw and transfer from any hyperchain in the ecosystem. These shared bridges are also responsible for deploying and maintaining their counterparts on the hyperchains. The counterparts will be asset contracts extended with bridging functionality.

To enable the bridging functionality:

• On the L1 we will add a Bridgehub contract which connects asset bridges to all the hyperchains.
• On the Hyperchain side we will add special system contracts that enable these features.

We want to make the ecosystem is as modular as possible, giving developers the ability to modify the architecture as needed; base token, consensus mechanism, staking, and DA requirements.

We also want the system to be forward-compatible, with future updates like L3s, proof aggregation, alternative State Transition Manager (STM) contracts, and ZK IP (which would allow unified liquidity between all STMs). Those future features have to be considered in this initial design, so it can evolve to support them (meaning, chains being launched now will still be able to leverage them when available).