Introduction to Chain Abstraction

One of the main differences between web3 and web2 applications is their ease of use. In web2, users are generally unaware of the complexities happening behind the scenes. For example, when sending an email through Gmail, the user simply types and clicks send. The system then handles server communications, data encryption, and spam filtering without any user intervention. Similarly, ordering food on UberEats involves integrating restaurant menus, payment gateways, and delivery tracking seamlessly. This is the same with payment systems, messaging services and others. All of this underlying complex technology is abstracted away from the user.

In fact, applications push it further by adding automated processes on top. Netflix doesn’t just abstract away the underlying tech, but deliberately starts the next episode without the viewer so much as pressing a button. These applications are in the business of extending the time spent as much as possible, and a clunky interface is as good as handing over their business to competitors.

A web3 application might not be more complicated than web2 ones that already handle billions of consumers. But they sure feel like they’re built only for the people with an IQ higher than Gary Kasparov. The amount of options and steps involved in using web3 is overwhelming for the average user. Users are confronted by a huge number of chains, bridges, and other pieces of connecting infrastructure. Managing multiple wallets and protecting seed phrases adds more complexity. All this needs to change if we want to build platforms that will power the next generation of consumer applications.

Chain Abstraction

Account abstraction has gained attention for good reasons. It is an important step forward in simplifying web3 UX. Features like passkeys, account recovery, and gas abstraction are valuable improvements. However, they address only a small part of the overall UX challenges.

The hurdle lies in the sheer number of rollup choices, L1s, bridges, and dApps to carry out actions beyond the account related problems. This fragmentation creates a complex and confusing landscape for users. Chain abstraction addresses these issues by extending the addressable UX problems to their maximum scope. The idea is to imagine an ideal state of user interaction, where, similar to the web2 experience, the user doesn’t need to understand what a blockchain or bridges are.

In an ideal world, using a web3 application should be as intuitive as sending an email or ordering food online. The user shouldn’t need to know which blockchain their transaction is on, how to choose the right bridge, or how to manage multiple wallets and seed phrases. Instead, all these complexities should be seamlessly handled in the background. This way, users can focus on their intended activities without being burdened by the underlying technical details.

Many efforts are underway to address this problem. The CAKE framework, Near protocol, Particle network — address these problems by dividing it into layers focused on each problem. Few projects are vertically integrating across the layers, while others focus on a single one. Broadly, there are account aggregation problems, routing problems, solving, bridge selection problems.

The Frontier group, with their CAKE framework has proposed a three-layered stack designed to tackle these problems systematically.

• Permission Layer: This layer handles accounts and permissions. It includes smart contract wallets and proxy services, which aim to abstract user interactions and maintain a balance between ease of use and user control.
• Solver Layer: The second layer focuses on solver markets and the competition among them. This layer addresses the routing problem by finding the optimal solution for users based on their preferences for speed, cost, and efficiency. Solver markets compete to provide the best routes for transactions, enhancing the overall user experience by automating the decision-making process and reducing the cognitive load on users.
• Settlement Layer: The final layer is responsible for settling interactions. It utilizes bridges, oracles, and other cross-chain solutions to ensure that transactions are completed efficiently and accurately. This layer abstracts the complexity of cross-chain interactions.

We’ll compare different solutions in these layers in detail later. ZetaChain is one of these solutions that addresses more than one problem.

On a high level, ZetaChain is a Cosmos SDK-based L1 using CometBFT. It is built to deploy omnichain smart contracts and provide a unified application experience. This is its core value proposition. Developers can deploy just a single contract and ZetaChain will take care of the cross-chain interactions. In the following sections, we will first explore how ZetaChain operates, and a high level understanding of its mechanics. Later, we will discuss the enhancements in version 2.0, highlighting the new features and improvements.

ZetaChain Architecture

ZetaChain components and their functions:

• Universal EVM: A modified Ethereum Virtual Machine (EVM) designed for building omni-chain apps.
• Communication Mechanism:
  • Omnichain: an interoperability layer that allows developers to build omnichain apps, which can be called from connected chains.
  • Connector API: point-to-point cross-chain messaging that supports arbitrary data and value transfer.
• ZRC-20: a standard for omnichain fungible tokens. Native gas and supported ERC-20 tokens can be sent from connected chains to omnichain apps as ZRC-20s. A ZRC-20 token can be withdrawn back to the connected chain.
• TSS Signers: Validators with additional responsibilities, including signing and monitoring outbound transactions.
• TSS Addresses: Specific addresses used for depositing tokens and initiating cross-chain interactions.

ZetaChain, like Near protocol and Lit uses Threshold signatures. A Threshold Signature Scheme (TSS) is a cryptographic method where a signature is generated collaboratively by a group of participants. It requires a minimum threshold number of participants (e.g., 3 out of 5) to produce a valid signature, with each participant holding a share of the private key. This enhances security by distributing the private key across multiple parties, protecting against single points of failure and ensuring fault tolerance.

On ZetaChain, observer-signer validators run two different pieces of software:

• ZetaChain Node: blockchain node that handles cross-chain transactions, management of ZRC-20 minting, omnichain app calls and more.
• ZetaClient: off-chain program run by observer-signers to observe transactions on connected blockchains and sign and broadcast transactions on connected chains on behalf of ZetaChain.

These TSS signers continuously monitor the deposit addresses across all supported chains, ensuring that they relay information upon successful transactions, triggering activities on ZetaChain. Additionally, they are responsible for signing outbound transactions, dispatched for processing on other chains.

This makes the contracts deployed on Universal EVM not just limited to ZetaChain. They can be called from connected chains.

Inbound Communication:

The user can interact with a dApp built on ZetaChain from any external chain. TSS observers monitor a special deposit address for native gas tokens and an ERC-20 custody contract for ERC-20 assets. A transaction to this deposit address or an ERC-20 custody contract is created with function call information embedded in it. The TSS observers verify and send this to the system contract, which calls the OnCrossChainCall function in the appropriate contract to execute it.

Outbound communication:

Contracts on ZetaChain can make calls to connected chains using the Connector API. A contract calls the Connector contract with details such as the chain ID, contract address, and message. ZetaChain then processes this call and forwards these details to the target chains, where the recipient contract’s “onZetaMessage” function is called.

These mechanisms ensure that ZetaChain contracts can both respond to and initiate requests wit