Translated by: Baihua Blockchain

Everyone is familiar with the issue of fragmented liquidity. The liquidity in the Ethereum ecosystem is dispersed across L1 and dozens of L2s.

On a Rollup, you cannot complete the following actions in a single transaction: borrow USDC on the mainnet Aave, exchange it for ETH on Uniswap, and then deposit it as collateral into a perpetual contract DEX. You must open a cross-chain bridge, transfer assets across chains, authorize here, send to there, cross-chain again, and finally deposit.

The Ethereum Economic Zone (EEZ) turns all of this into a single transaction. Rollups in the EEZ can access all resources on Ethereum and other EEZ Rollups as if they were on the same chain (synchronous composability).

What is EEZ

EEZ consists of contracts on Ethereum and rules connecting various chains to these contracts. It is not a new chain, nor a new stack. A connected chain can utilize resources on Ethereum or any other connected chain in a single transaction. This idea stems from execution sharding, an old Ethereum scaling plan, and real-time proving makes it a reality.

The starting point of EEZ is: the number of chains around L1 will not decrease. Even when pushed to the limit, L1 cannot support the global economy; it lacks sufficient bandwidth. Moreover, not everyone is suited to stay on L1—no one on L1 will help you correct mistakes, and banks or trading platforms require different rules. The chains will each be different, covering EVM and non-EVM, public, private, or permissioned chains, and our task is to make them work together as a whole.

Each chain within the zone still runs transactions according to its preferred virtual machine (VM) and order. It also decides who to allow in and which proofs to trust. What all chains within the zone share are Ethereum blocks. Each of them can utilize liquidity, contracts, and keys on L1 within the same block. The name "Economic Zone" comes from this—a region with a shared market, but where each chain has its own independent rules.

To join EEZ, a chain must meet at least two conditions: prove its state within a slot, and rollback together with Ethereum during a reorganization. The second condition is to prevent any transaction from remaining on a chain while its counterpart disappears from Ethereum after a reorg. EEZ contracts do not see what happens inside the chain; they only require proof and state root (the hash value that commits to the entire state of the chain) from that chain. The chain can have any VM and any admission rules, with no mandatory requirement for specific provers. Existing L2s can join.

Technically, EEZ relies on three core components:

• Real-time proving. The chain proves its new state within an Ethereum slot.

• Composer. An operator that pre-runs transactions on each involved chain before block generation to prepare answers for cross-chain calls.

• Proxy. A contract on one chain that represents a contract on another chain.

What is Real-time Proving

Validity proof is used to indicate that a chain has achieved a new state by following its rules. Contracts on Ethereum can verify it without re-executing the blocks of that chain. Real-time proving means that the proof is ready within one Ethereum slot—which is within 12 seconds.

A year ago, real-time proving caused a huge sensation. At that time, ZisK required 24 RTX 5090 graphics cards, while today only 4 are enough (Ethproofs).

EEZ needs it because Ethereum does not execute Rollup's code; it only accepts Rollup's responses under accompanying proof. In the past, generating proofs took minutes or even hours, and responses could not arrive within the same block where the call was initiated; whereas proofs completed within a slot make all of this possible.

In the design of EEZ, the response to cross-chain calls from Rollups is prepared before block generation. The composer calculates the results, the prover proves the results, and the builder packages the proof along with the transaction that needs the response into an Ethereum block—all of these operations must be completed within the same 12 seconds.

How Synchronous Calls Work

The easiest way to understand this process is to look at a single call from Ethereum to a Rollup (the calling path between two Rollups is the same).

• Proxy

  Calls to another chain are made through a proxy. Each contract on a Rollup has a pre-defined proxy address on Ethereum, and vice versa. This address is calculated using CREATE2, based on the EEZ contract address, the original contract address, and the chain ID in the EEZ registry. Anyone can deploy the proxy to that address. From the perspective of the calling contract, the proxy behaves like any other local contract. Cross-chain calls are written in code like ordinary calls, without the need for a messaging protocol.

  

• Composer and the Execution Table

  The composer runs the transaction on each chain involved and records each cross-chain call in an execution table—a table of pre-calculated answers. Each entry (execution entry) contains the answer to the call, the state roots of the Rollup before and after the call, the list of calls that the Rollup will callback to Ethereum, and the rolling hash of these calls and their results. A single proof can cover the entire table.

  

The composer sends a transaction bundle to the builder; the builder either includes this set of transactions in order completely or does not include it at all. The first transaction in the bundle is a postAndVerifyBatch transaction, which includes the Rollup's batch, execution table, and proof; the user transaction follows. The cross-chain part on the Rollup is executed in a synchronous block (Sync block), and the Rollup generates a synchronous block for each Ethereum block and binds it to it. If the transaction bundle misses that block, the synchronous block will rollback.

• Verifying the Batch and the Proxy's Response

  The postAndVerifyBatch transaction verifies the proof of the batch. The proof systems trusted (ZK, TEE, multi-signature, or their combinations) and how many proofs are needed for each batch are determined by the Rollup's owner; EEZ does not endorse these systems. Each proof in the batch must be verified. After that, the EEZ contract stores the entries of the execution table and the state root transitions, allowing the proxy to check and apply this data when the calls arrive.

  

Next, the user's transaction is executed. When it calls the proxy, the proxy looks up the entry for that call in the EEZ contract and only gives a response if the following conditions are met: the call matches exactly what the composer simulated, the entry arrived together with the batch of that block, and the rolling hash produced by the Rollup matching the callback to Ethereum.

• Callback to Ethereum

  Calls from the Rollup back to Ethereum are executed directly by Ethereum, while the Rollup retrieves the answers for these calls from the composer’s simulation. Calls can be nested—Ethereum contracts that get called this way can again call contracts on the Rollup through a proxy, and the answers for that nested call already exist in the execution table.

  

• The Initial Transaction

  This transaction direction is the opposite, going from Rollup to Ethereum. Before block generation, the composer executes the transaction on both chains and writes everything that your wallet will recover into the execution table. The builder puts the batch with the execution table and proof into an Ethereum block, the EEZ contract verifies it, and then the transaction is executed in the Rollup's sync block. The calls to Aave and Uniswap are executed on Ethereum by the transactions in the same transaction bundle from the composer, while you cover the L1 gas fee by tipping the composer higher.

1. The wallet calls Aave's proxy on the Rollup and borrows USDC. Aave sees your wallet proxy on Ethereum as the borrower (the collateral must be pre-deposited at that address).

2. The wallet exchanges USDC for ETH through Uniswap's proxy and reads the answer from the execution table.

3. The cross-chain bridge records this ETH on the Rollup.

4. The wallet deposits that ETH as margin into the trading platform.

If the composer finds any failing steps in the simulation, it will not send the transaction bundle. If the actual execution results on Ethereum do not match the simulation, all operations on both Ethereum and Rollup will rollback.

What Changes Does This Bring

The above transaction demonstrates only one possibility. Calls can be made in all directions: L1 → L2, L2 → L1, or L2 → L2.

Any Rollup Can Share Liquidity on Ethereum

New chains in the EEZ do not need to cold start liquidity through token incentives; they can directly use existing liquidity and applications on L1. On a test Rollup RollupX located in the EEZ on the mainnet, someone purchased CRV from Ethereum's Uniswap pool. At that time, CRV did not exist on the Rollup at all; the cross-chain bridge minted wrapped CRV directly in the same exchange transaction (tx).

When each EEZ chain does this, the transaction volume aggregates into the same L1 liquidity pool, rather than fragmenting across various chains. Other protocols on Ethereum also do not need to be repeatedly deployed on each chain. The gas for these calls is paid on L1, the more activity there is on EEZ chains, the greater the demand for Ethereum block space.

The introduction of Rollups is meant to control transaction ordering and retain MEV, while trading platforms also seek to have customized matching engines. The past cost was sacrificing composability with Ethereum, as contracts and liquidity on L1 could only be used asymmetrically by Rollups. In EEZ, trading platforms can match orders with their own engines, while portions of the order book that cannot be executed will be directly executed against liquidity pools on Ethereum within synchronous blocks.

Key Management on L1

Keys and permissions can remain on L1, as contracts on Rollups can read the state of Ethereum within the same transaction. Multi-signature wallets like Safe have already operated this way on RollupX. The Safe on the Rollup does not store the owner list, but reads it from the Safe on Ethereum for each transaction. Simply change the owner or revoke a key once on L1, and from the next transaction onwards, it will be effective on all chains that read the owner from L1. The cost is that each transaction of that Safe needs to initiate a cross-chain call and wait for the next synchronous block. Safes on Ethereum and Safes on Rollups can jointly manage a treasury—they share the same budget, and both parties require just one signature to make a payment.

Permissioned and Private Chains

Chains in the EEZ do not have to be public chains. Privacy chains like Aztec, or permissioned chains operated by governments, can join the EEZ and utilize L1 liquidity. The closest existing instance is the privacy pool Bermuda Bay on RollupX—it conceals the identity of traders while performing exchange operations on Uniswap V3 on L1 in the same transaction (tx).

Rollup as Co-processor

Rollups can act as co-processors for Ethereum. Tasks that are too costly to compute on L1 can be performed on Rollups, and contracts on Ethereum can act based on their results within the same block. Verifying a quantum-resistant Falcon signature on Ethereum consumes 5.5 million gas; while in EEZ's demonstration, that signature was verified on the Rollup, and its result directly authorized a payment on L1's Safe without any precompiled contracts or hard forks. As long as new cryptography and new virtual machines exist on chains within the economic zone, Ethereum can directly use them.

Limitations

Chains within the EEZ cannot simultaneously enjoy rapid block generation, synchronous calls with Ethereum, and decentralized order matching—they must choose two out of three (Gnosis forum). For example, a fast chain with a block generation speed of 200 milliseconds requires a centralized order matcher to achieve synchronous calls with Ethereum. Only 1 out of every 60 blocks is a synchronous block, and applications on that chain can only reach Ethereum once every 12 seconds. However, that chain remains operational; it's just that the cross-chain part operates at L1 speeds and relies on L1's block space.

Each cross-chain call must go through the composer. It must see the unencrypted transaction before block generation, hence the composer and builders will be prioritized for MEV from it.

Currently, 7% of Ethereum blocks are built by validators themselves, without external builders. No synchronous calls happen in those slots.

In the first month of its launch, every EEZ batch ended up in blocks built by external MEV-Boost builders. Among them, 56% of batches entered blocks built by Titan (while Titan's normal block production share is 48%). Interestingly, Titan is now also able to capture cross-chain MEV.

With EEZ, Rollups no longer need to choose between "running a standalone chain" and "staying on Ethereum." They retain control over transaction ordering and rules while seamlessly using Ethereum's liquidity and applications within the same block.

Link to the article: https://www.hellobtc.com/kp/du/11/6498.html

Source: https://x.com/0xJaehaerys/status/2120505244690120808