How close are we to a future of chain abstraction?

Author: Rui, SevenX Ventures investor; Translation: 0xjs@黄金财经

In the Rollup craze, we can only achieve this by simplifying the complexity of infrastructure for users. This means that all cross-chain operations require one account, one signature, and one Gas. However, challenges still exist, such as account state synchronization, signature aggregation, atomic execution, and delayed finality.

1. What is chain abstraction

In the final stage, end users will not need any basic knowledge. They only need to express their intentions or specify orders, sign transactions, and leave the rest of the work (routing, Gas conversion, construction, orders, and cross-chain operations) to be handled automatically. This article focuses on cross-domain abstraction in particular.

2. Why chain abstraction is important

With the help of fat protocol theory, blockchain Rollup or alternative L1 builders are multiplying, and Rollup-As-A-Service is speeding up the creation of new blockchains to within a day. That being said, those blockchains that lack activity will disappear within 6-18 months. Still, the realization of a unified blockchain monopoly seems unlikely due to the continued need for flexibility. Even in a more centralized long-term scenario, the existence of various blockchains will continue to lead to fragmented user experience and liquidity.

3. Chain abstraction decomposition

Unified address: The wallet merges different EVM and non-EVM addresses into one.  

Signature aggregation: The smart contract account (EVM) or MPC signer contract (non-EVM) manages signature aggregation.  

State synchronization: Keystore Rollup or Hub facilitates cross-chain wallet state synchronization.  

Single Gas: The Paymaster contract supports the use of ERC20 payments and even sponsors all payments.  

Block construction and relay: Mempool builders verify, sort, and batch transactions, while RPCs monitor the status of each transaction on each chain and coordinate execution in order.  

Unified liquidity: Cross-chain liquidity is handled by Solvers such as UniswapX or liquidity hubs.

4. Who are the main players?

Chain abstraction is at the intersection with wallets, intent-based systems, MEV solutions, and bridges.

Key projects such as Safe, Clave, Flashbot, LayerZero, Union, others play active or passive roles.

This year, specific chain abstraction participants aim to integrate various modules into a unified front-end solution, for example,

Particle Network developed a layer 1 solution using the Cosmos SDK, allowing users to use any token or PARTI as Gas for transactions across EVM, Solana, and BTC.

Light provides a 4337-compatible cross-chain smart contract wallet that supports state synchronization and signature aggregation,

Burnt (xion) is a general chain abstraction protocol with a meta-account design that allows agnostic signatures, parameterized fee layers, and state machine updates.

NEAR Protocol integrates the MPC layer to solve cross-chain transactions.

5. Multi-chain unified address

Maintaining separate accounts for each chain is a burden for both users and developers, requiring the latter to manage multiple code bases. For smart contract wallet projects, such as

Particle Network and Light can use a deterministic deployment agent that can be deployed to any chain at the same address within the EVM and use CREATE2 to deploy any contract in a deterministic location. For external blockchains, addresses can be derived from the EVM address, chainID, and the provided path, and each account receives an unlimited number of remote addresses on each chain. For EOA accounts, for example, the NEAR protocol derives an external address from the NEAR address (example.near), the derived path (such as a string for Ethereum-1), and the public key of the MPC service.

6. Cross-chain wallet state synchronization

When a user changes the signing key at layer 2, how is the change synchronized to other chains? It requires real-time updates, minimal update costs, and reasonable propagation times. Here are three current solutions: Keystore rollup, Light sync, and Keystore hub.

Keystore rollup

In Vitalik Buterin's design, the minimal Keystore rollup is a Rollup based on L1 sorting, storing its Merkle tree state root on L1. To create a wallet, the user creates a zk circuit that defines the logic for verifying and updating signers, and each user has data + verification key (vk). The user creates a SCW and hardcodes their key as an immutable value. To change the SCW signer through this L2, the user can submit their original key, the new key, the current vk, the data value encoded in the IMT, and a proof of verification against the current vk. Alternatively, the user can submit tx directly to the Keystore contract on L1.   

This approach is neutral and trustless, however, incentives can be challenging, assuming updating signers is not a frequent behavior, users must pre-pay tx proofs to subsidize Rollup provers, otherwise no value is provided to the prover.

Light State Sync

Light implements light wallet sync, invented by Agusx1211 from 0xsequence. It enables wallets to create custom message modes in SCA that are not attached to the network chainID, allowing "control delegation" signatures to be signed to a new set of signers, and these signers can later be used to sign any regular transaction or message. However, the state is not updated until a user acts on either chain, and another transaction can be tagged as one of the baching tx to update the chain state to match the latest "pre-signed" state.  

This method achieves real-time and cost-effectiveness, but it relies heavily on the availability of off-chain data. If the data is lost, the wallet will not be able to access its latest state or even become unusable, so the wallet client is usually responsible for storing a copy of all data. In addition, this method does not provide strong guarantees when deleting signers because it does not disable anything on the chain.

Keystore Hub

Particle Network uses Keystore Hub. The code logic and storage of smart accounts are separated, the keystore hub stores signer information, and users deploy and update through the Hub to ensure the consistency of multi-chain status. In short, the Keystore center is responsible for sending updated transactions to different chains.  

This method is the most direct method, assuming that updating the signer operation is not a frequent operation, so the batch transaction fee is acceptable, however, it requires trust and some delays.

7. Signature Aggregation

Users can now initiate multi-chain transactions with a single signature. Projects such as Light use full-chain signature aggregation based on Merkle Tree to ensure that users only need to sign once. However, when it comes to non-EVM, projects like NEAR utilize MPC signer contracts, which will return the elements needed to reconstruct the signature instead of the signature of the tx itself, allowing them to generalize the signing process of multiple blockchains (i.e., in Bitcoin, return r and s values) and forward them to the corresponding network. It should be noted that the signatures of the payer (sponsor gas) need to be collected and aggregated in this process if necessary.

8. Gas abstraction

A better experience is that Gas is sponsored by other parties (wallets or dApps) or paid in erc20. More importantly, in cross-chain scenarios, unified Gas reduces complexity. Gas includes execution fees for all related chains. In the process of building tx, Paymaster signs a contract with the participants by providing its own signature. When Bunler performs off-chain simulation, it checks the balance of Paymaster. Paymaster returns Gas directly to the Bundler target chain when executing on Bundler.

Layer1 is similar to Particle Network, allowing users to pay and process cross-chain gas in any token or PARTI;

Light allows payment with any token and custom payer to fully sponsor the Gas of a specific order flow;

Clave currently sponsors the Gas of "all" user transactions.

9. Block Construction

At a high level, we will have a plug-and-play memory pool and decentralized block builder to process transactions. User preferences range from simple transfers within a single domain to complex sequences across multiple blockchains. Users can specify execution details within a domain or provide abstract instructions, leaving the best route to the executor.

The concept of SUAVE depicts an ideal scenario: multiple chains share a decentralized sorting layer, maximizing the network resilience and block space income of validators while ensuring open access for builders and searchers.

10. Relay

In order to achieve cross-chain atomicity, the relay work is closely related to block construction. The relay node/such as Flashbots RPC monitors the tx execution on each chain and coordinates the bundler/builder to send the next tx to the corresponding chain. Repeat the process until all transactions are executed on the target chain and unused Gas fees are processed.

In theory, the waiting time is the block time of the blockchain. When the block is too slow, the signature will be invalid. We can set tx to be atomic, so that when one tx fails, the entire tx will fail.

11. Particle Network

Particle built a modular Cosmos L1 as a universal settlement layer, supporting chain abstraction across EVM, BTC, Solana, etc. By using the previous wallet-as-a-service integration and BTC connect as the entry point, handling account storage and synchronization through the keystore contract in the EVM, they leveraged the decentralized bundler service to build UserOps, messaging protocols for cross-chain transactions, and relayers responsible for the entire execution lifecycle. With PARTI as the center of the Particle chain, gas on Particle and other chains can be abstracted. On top of the base layer, L1 can leverage the security of Babylon double staking and adopt aggregated DA. Particle Chain will become a one-stop solution for end users and dApps.