[Astar Series] #2: Astar zkEVM, To Achieving Scalability and Interoperability

Key Insights

• Many projects are currently developing zkEVM, which can be broadly classified into four stages based on performance and EVM compatibility.

• Astar zkEVM, developed using Polygon CDK, is a Type 2.5 or Type 2 zkEVM, and this article analyzes the structure of Astar zkEVM.

• Historically, Astar zkEVM has pursued a vision of multi-chain and interoperability within the Polkadot ecosystem through XCM, and it aims to expand this vision of interoperability through future connections with Polygon AggLayer.

1. Astar's Tech Eclipsed by Business

In the [Astar Series] #1, we briefly explored the history and overview of the Astar Network. Known for its business acumen among large-scale Web2 companies and cities in Japan, Astar Network equally boasts significant technical prowess. From its inception within the Polkadot ecosystem, it has been dedicated to developing solutions for scalability and interoperability and now aims to advance further with the implementation of Astar zkEVM. The upcoming [Astar Series] #2 will delve into the diverse technical features of the Astar zkEVM.

2. Overview of zkEVM

2.1 zkEVM

Rollups consolidate multiple transactions into a single block to improve Ethereum's scalability. They are classified into Optimistic Rollups (ORUs) and Zero-Knowledge Proof Rollups (ZKOs) based on how they verify off-chain transaction validity. ZKOs use cryptographic zero-knowledge proof (ZKP) techniques to verify transactions off-chain and submit updated state data on-chain along with proofs.

Initially, ZKO like Loopring, zkSync Lite, and immutable were developed as Application-Specific Rollups, performing tasks like token swaps and payments. These rollups offered low fees and scalability but had limitations in executing general-purpose smart contracts through ZKP computations, as Ethereum's Virtual Machine was not designed with ZKP computations in mind.

zkEVM represents an effort to develop a virtual machine that retains the Ethereum Virtual Machine environment while supporting ZKP computations used in implementing ZKO. Initially, there were significant challenges in implementing zkEVM for various reasons, and it was expected that launching a general-purpose ZKO would take time. However, several projects have recently successfully launched a mainnet capable of performing general computations through ZKO.

2.2 zkEVM Process

The general process of zero-knowledge proof rollups can be simply expressed as follows:

1. Transactions occurring off-chain are processed by an execution engine (e.g., Geth, Nethermind).

2. Subsequently, zkEVM is utilized to prove the validity of the transaction executions (the implementation of zkEVM varies by project).

3. zkEVM employs ZKP technology to generate a proof, which is then submitted on-chain (e.g., Ethereum) along with the updated state.

4. Finally, the validity of the submitted proof is verified through a smart contract deployed on-chain."

2.3 Type of zkEVMs

In August 2022, Vitalik Buterin categorized zkEVM into four types based on EVM compatibility and performance in “The different types of ZK-EVMs”. The numbers following each type simply reflect a trade-off between EVM compatibility and performance due to differences in implementation methods, rather than indicating a hierarchy of quality. Here is a summary of the types:

• Type 1 (fully Ethereum-equivalent): This type maintains a state completely equivalent to Ethereum, including hash functions, the state tree, and gas costs. It has the advantage of allowing easy migration of Ethereum's dApp infrastructure. However, it may take a long time to generate proofs. Currently, Taiko is the only project actively developing a Type 1 zkEVM and is operational as a testnet.

• Type 2 (fully EVM-equivalent): This type makes slight modifications to Ethereum's data structures and tree configurations to facilitate ZKP computations, addressing one of the downsides of Type 1—long proof generation times. While it maintains compatibility with the existing Ethereum infrastructure, it is not completely equivalent to Ethereum. This type still requires significant resources to generate proofs, which has led to the adaptation known as Type 2.5 zkEVM, where gas costs are adjusted.

• Type 3 (almost EVM-equivalent): This type improves proof generation times by removing certain EVM features, specifically the Precompiles, which handle specific operations like hashing and signing. There are nine Precompiles in EVM. Type 3 zkEVM offers the advantage of faster proof generation times. However, dApps that utilize Precompiles would need to modify their code. Currently, most zkEVM projects fall under Type 3 or Type 4, with ambitions to achieve Type 1 or Type 2.

• Type 4 (high-level-language equivalent): This type involves developing a general-purpose VM and creating a programming language that is friendly to ZKP computations. While it can significantly reduce development resources, it struggles with compatibility with the existing Ethereum infrastructure. This means it is more compatible with Solidity than with EVM. Moreover, due to different bytecode compilation methods, it faces the challenge of not sharing the same address system as Ethereum. Projects like zkSync Era and StarkNet fall under Type 4 zkEVM.

Each type has its own advantages and disadvantages, which led to their classification into these four categories during the early stages of zkEVM development. Recently, projects within Type 3 have been making efforts to improve EVM compatibility, aiming to transition to Type 2.

Type 3 zkEVM supports EVM bytecode, which allows compatibility with most apps and tools. However, because it does not support some opcodes and precompiles, developers might need to make minor code modifications. The list of incompatible codes includes:

• opcode: SELFDESTRUCT, EXTCODEHASH, DIFFICULTY, BLOCKHASH, NUMBER

• precompile: SHA256, BLAKE, PAIRINGS

Recently, Polygon zkEVM has begun to support opcodes such as BLOCKHASH, DIFFICULTY, EXTCODEHASH, NUMBER, and precompiles like SHA256, through the Etrog upgrade. It continues to update incompatible opcodes, precompiles, and EIPs. Similarly, Astar zkEVM, using the same stack, is evolving from Type 3 to Type 2.5 or Type 2, thus providing a more developer-friendly environment.

3. Astar zkEVM Based on Polygon CDK

3.1 Polygon CDK

At the end of August 2023, Polygon unveiled the Polygon Chain Development Kit (CDK), adopting a strategy similar to Optimism's SuperChain, Arbitrum's Orbit, and ZkSync's ZK Stack. The Polygon CDK is a modular open-source software toolkit that assists blockchain developers in easily building new L2 chains on Ethereum. This tool enables the easy construction of rollups by allowing customization of various components, including the data availability layer and native gas tokens, thereby expanding the ecosystem as an L2. Additionally, it offers cross-chain functionalities that enable chains developed with the Polygon CDK to interoperate through the Aggregation Layer (AggLayer). Currently, several projects are using the Polygon CDK to develop rollups, including Astar zkEVM.

3.2 Astar zkEVM Architecture

Astar zkEVM is a chain built using the Polygon CDK and utilizes a technology stack almost identical to that of Polygon zkEVM. It is composed of the following components:

• Pool DB: Functions similarly to a mempool, containing transactions submitted by users through RPC nodes.

• Sequencer: Verifies the validity of transactions waiting in the Pool DB and includes them in a batch. It then sends a batch proposal to the Ethereum network.

• State DB: A database that permanently stores state data.

• Aggregator: Observes batches proposed by the sequencer and generates the corresponding ZKP for Ethereum submission via zkProver.

• Synchronizer: Fetches data from Ethereum and updates it in the State DB.

Thus, transactions submitted by users are included in a batch by the Sequencer, and the Aggregator generates a zkp for this batch, which is then submitted to the Ethereum network to finalize the state, updating the State DB accordingly. Unlike Rollups, which uses the Ethereum network as a Data Availability (DA) layer, Astar zkEVM manages data availability with a separate DAC, slightly compromising security for improved scalability.

With chains developed using the Polygon CDK that utilize the DAC method, only the hash values of data are published on the Ethereum network. Participants of the DAC personally verify the submitted hash values and send their verification as a signature to the Sequencer. This process involves multisig and requires a certain number of signatures to ensure data availability.

3.3 zkProver

In addition to executing the zkNode client, the Aggregator needs to run zkProver to generate proofs for batches. zkProver is comprised of various state machines. The main state machine is responsible for executing transactions and converting the resultant EVM bytecode into the zkASM language, which is optimized for proof generation. Transactions and data are then transformed into polynomial form. STARK Builder takes these polynomials and generates the corresponding zk-STARK proofs. Since these proofs are generated recursively, hundreds of zk-STARK proofs can be consolidated into a single proof. While STARK proofs are fast to generate, they have the drawback of being large in size. To address this, zkProver produces SNARK proofs corresponding to the STARK proofs to reduce their size significantly, compressing gas costs from 5M to merely 350k.

4. Toward the Ultimate User Experience(UX): The Importance of Interoperability

4.1 XCM

Long before connecting to the Polygon Agglayer through Astar zkEVM, the Astar Network has emphasized the significance of enhancing the user experience through interoperability and the vision of a multi-chain future, as articulated here. A prime example of this commitment is XCM. XCM, short for Cross-Consensus Message Format, facilitates communication across different consensus systems and stands as a hallmark messaging format within the Polkadot ecosystem.

There are two common misconceptions about XCM. Firstly, XCM is not a protocol layer but a messaging format for the exchange of arbitrary data between chains, independent of the actual message transmission, which is handled by protocol layers such as XCMP, HRMP, and VMP. Secondly, XCM's utility extends beyond the Polkadot ecosystem; while it is a prominent feature within Polkadot, enabling communication between parachains connected to the Polkadot Relay Chain, its design allows for universal application in any system with consensus-based finality.

XCM enables functionalities like 'Remote Transfers'—akin to Cosmos' ICA—that allow control over accounts on other chains to facilitate asset movement, and 'Asset Teleportation,’ which involves burning assets on one chain and recreating them on another. These capabilities significantly enhance the user experience within the interconnected parachains of the Polkadot ecosystem.

Thanks to the Substrate SDK, networks built with it can easily incorporate the XCM pallet module, thus benefiting from XCM's features. This applies to the Astar Parachain as well, which currently offers a variety of XCM functionalities. From conducting 'Native XCM Transactions' involving the transfer of DOT tokens to Astar Parachain to creating and utilizing universal chain assets like 'XC20 Assets', executing transactions on other chains through 'Remote Transact,’ and transferring assets from one network to another with 'Transfer Reserve Assets', developers can offer users seamless cross-chain experiences on the Astar Parachain.

4.2 AggLayer

With a similar vision in mind, Astar Network aims to achieve this through the Polygon AggLayer. Astar zkEVM is the first network to connect to the AggLayer outside of the Polygon-associated networks. AggLayer, a protocol that aggregates and compresses ZKPs for final submission to Ethereum, enables networks capable of proving transactions through zk-proofs, regardless of being L1 or L2, to connect. The aggregation of ZKPs from networks connected to AggLayer offers significant advantages for cross-chain messaging.

The first advantage is validity; in cross-chain messaging, ensuring the validity of transactions from other networks is crucial, and networks connected through AggLayer can easily verify this through zk-proofs. The second is sovereignty; while shared sequencers for atomic transactions might require networks to sacrifice sequencing and MEV revenues, networks on AggLayer can maintain their own sequencers (or validators) and still enjoy the benefits of atomic transactions. Overall, the seamless cross-chain messaging possible between networks connected to AggLayer can significantly enhance the user experience.

In the AggLayer, two primary cross-chain messaging scenarios exist: the asynchronous and synchronous cases. Traditionally, the process involves each chain's ZKPs being submitted to the AggLayer, followed by a compression of these proofs into a final submission to the Ethereum network for validity verification before any cross-chain messaging occurs, as depicted in the figure to the left. However, this method can delay user experience due to its time-consuming nature.

To address this, the AggLayer supports an optimistic approach where validity is verified post-factum (as shown in the middle of the picture). This method allows for cross-chain messaging based on batches submitted to the AggLayer from one chain before the ZKP is generated, with validity verification occurring afterward. If any issues arise, rollback and slashing procedures are enacted. While this approach simplifies the process, it operates asynchronously, meaning transactions execute sequentially across chains, not simultaneously.

To overcome this limitation, the AggLayer also facilitates atomic transaction processing (illustrated on the right of the picture). Here, users submit a transaction bundle to the AggLayer. The transactions within this bundle are dispatched to their respective chains, where the affected states are temporarily frozen. Once all transactions execute correctly, each chain generates a ZKP, and if no issues are found, the frozen states are unlocked.

Leveraging these features, users of Astar zkEVM can interact with multiple networks connected through the AggLayer, feeling as though they are engaging with a single network. For example, users of the Astar zkEVM will be able to deposit their ETH with a single click to any rendering protocol on the network connected to the AggLayer.

5. Looking Ahead

Recently, numerous projects have been exploring the concept of chain abstraction in various ways. On the mainnet level, initiatives include the Near Protocol's decentralized frontend and Polygon's AggLayer, while on the application level, efforts like UniswapX and Across aim to utilize intent. The focus is on providing a user experience that feels seamless across multiple networks, akin to interacting with a single service.

Astar Network has been focusing on the future of multi-chain and chain abstraction even before these concepts gained widespread attention and aims to realize this vision through Astar zkEVM. The potential new forms of user experience that Astar zkEVM could offer in collaboration with Polygon AggLayer are noteworthy. The final article of the Astar Series will explore the ecosystem surrounding Astar zkEVM.

Thanks to Kate for designing the graphics for this article.