Breaking L2 Liquidity Silos: The Underlying Logic of the Ethereum Economic Zone (EEZ) and a New Cross-Chain Solution
In the architecture of the Ethereum Economic Zone (EEZ), the core goal of the cross-chain mechanism is to achieve “Synchronous Composability.” To fully understand it, we can break down the process into two key questions: “Why is a cross-chain mechanism needed?” and “Why must everything be completed within the same Ethereum block?”
I. How does the cross-chain mechanism work? (The three pillars of EEZ)
With traditional cross-chain bridges, Chain A and Chain B operate asynchronously: you have to lock funds on Chain A, wait for multisig signers or validators to confirm, and then mint assets on Chain B. The process is slow and prone to failure. EEZ, by contrast, uses a mechanism of “synchronous coordination based on proofs and proxies,” relying mainly on three components:
Real-time proving:
In the past, generating a validity proof for a Rollup could take minutes or even hours.
EEZ uses the latest hardware and real-time proving technology to generate proofs within a single Ethereum slot (12 seconds). The Ethereum mainnet does not need to re-execute the Rollup’s code; it only needs to verify this real-time proof to confirm that the Rollup’s state is correct.
Composer and Execution Table:
The Composer is a key operator. Before an Ethereum block is produced, the Composer pre-executes the transaction across the chains involved in cross-chain calls and records the result of each call in a “precomputed answer table” (the Execution Table).
Proxy contracts:
Every contract on a Rollup has a predetermined proxy address on Ethereum L1 (and vice versa).
When a cross-chain call occurs, the code is written just like an ordinary local contract call, with no need for a complex asynchronous messaging protocol. The proxy looks up and verifies the Composer’s precomputed execution result in the EEZ contract, and directly allows the call to proceed if the result matches.
II. Why must everything be completed within a single Ethereum block? (The key reasons)
“Completing everything within the same Ethereum block” (i.e., synchronous calls) is the heart of the entire mechanism. There are three main reasons:
Eliminate the lack of “atomicity” and achieve true “all or nothing” execution
Atomicity is crucial in financial and complex smart contract operations: a transaction involving multiple steps must either succeed in its entirety or fail in its entirety.
The problem with asynchronous cross-chain transactions: If you perform operations in stages (lending on L1, bridging across chains, then trading on L2), and the second step gets stuck midway or the market moves sharply, your assets are exposed to significant risk. For example, funds may have left L1, but the trade fails in the target pool on L2 for some reason, leaving the funds stranded mid-transfer.
The advantage of synchronous execution within one block: If all operations are bundled into the same Ethereum block, the entire transaction chain is fully atomic. During its simulation, if the Composer finds that any step (such as excessive slippage or insufficient balance) would fail, the entire transaction bundle is canceled before the block is produced. If it is included on-chain, then if even one part encounters a problem, all related operations on Ethereum and the Rollup are immediately and safely rolled back. This completely eliminates the intermediate risks of cross-chain transactions.
Eliminate liquidity fragmentation and let L2s share L1’s deep liquidity pools in real time
If cross-chain operations are not completed within the same block, you have to move funds in advance to pools on each L2 and lock them there, resulting in serious capital inefficiency and liquidity fragmentation.
Within the same Ethereum block, a Rollup can directly “borrow” the deep liquidity of the Ethereum L1 mainnet (such as Uniswap or Aave) at the very moment a call is initiated.
For example, you trigger a transaction on L2, and within the same Ethereum block it directly calls Uniswap on L1 to complete a swap and return the result. To the user, it feels just like operating on a single chain; there is no need to “top up” or move funds between chains in advance.
Avoid state desynchronization and “reorg” attacks
Blockchains can experience reorganizations (reorgs) at any time. If cross-chain transactions are asynchronous and span multiple blocks, Chain A may consider a transaction successful, only for a subsequent reorg on the Ethereum mainnet to erase the upstream state that Chain A relied on. This can cause catastrophic accounting discrepancies.
Requiring everything to be completed within the same Ethereum block means that all state transitions, proof verifications, and proxy callbacks are bound to the same time anchor (the Sync block).
Chains joining the EEZ must abide by an ironclad rule: when Ethereum undergoes a reorg, the chain must roll back in sync. This guarantees at the underlying level that cross-chain states will never become inconsistent due to a “time lag.”
💡 In a nutshell:
Keeping everything within the same Ethereum block means using the blockchain’s most fundamental and robust property—“atomicity”—in place of fragile, time-consuming cross-chain bridges. This lets applications distributed across different L2s share all of the Ethereum mainnet’s liquidity and computational resources instantly and securely, as if they were running on the same CPU core.
In the architecture of the Ethereum Economic Zone (EEZ), the core goal of the cross-chain mechanism is to achieve “Synchronous Composability.” To fully understand it, we can break down the process into two key questions: “Why is a cross-chain mechanism needed?” and “Why must everything be completed within the same Ethereum block?”
I. How does the cross-chain mechanism work? (The three pillars of EEZ)
With traditional cross-chain bridges, Chain A and Chain B operate asynchronously: you have to lock funds on Chain A, wait for multisig signers or validators to confirm, and then mint assets on Chain B. The process is slow and prone to failure. EEZ, by contrast, uses a mechanism of “synchronous coordination based on proofs and proxies,” relying mainly on three components:
Real-time proving:
In the past, generating a validity proof for a Rollup could take minutes or even hours.
EEZ uses the latest hardware and real-time proving technology to generate proofs within a single Ethereum slot (12 seconds). The Ethereum mainnet does not need to re-execute the Rollup’s code; it only needs to verify this real-time proof to confirm that the Rollup’s state is correct.
Composer and Execution Table:
The Composer is a key operator. Before an Ethereum block is produced, the Composer pre-executes the transaction across the chains involved in cross-chain calls and records the result of each call in a “precomputed answer table” (the Execution Table).
Proxy contracts:
Every contract on a Rollup has a predetermined proxy address on Ethereum L1 (and vice versa).
When a cross-chain call occurs, the code is written just like an ordinary local contract call, with no need for a complex asynchronous messaging protocol. The proxy looks up and verifies the Composer’s precomputed execution result in the EEZ contract, and directly allows the call to proceed if the result matches.
II. Why must everything be completed within a single Ethereum block? (The key reasons)
“Completing everything within the same Ethereum block” (i.e., synchronous calls) is the heart of the entire mechanism. There are three main reasons:
Eliminate the lack of “atomicity” and achieve true “all or nothing” execution
Atomicity is crucial in financial and complex smart contract operations: a transaction involving multiple steps must either succeed in its entirety or fail in its entirety.
The problem with asynchronous cross-chain transactions: If you perform operations in stages (lending on L1, bridging across chains, then trading on L2), and the second step gets stuck midway or the market moves sharply, your assets are exposed to significant risk. For example, funds may have left L1, but the trade fails in the target pool on L2 for some reason, leaving the funds stranded mid-transfer.
The advantage of synchronous execution within one block: If all operations are bundled into the same Ethereum block, the entire transaction chain is fully atomic. During its simulation, if the Composer finds that any step (such as excessive slippage or insufficient balance) would fail, the entire transaction bundle is canceled before the block is produced. If it is included on-chain, then if even one part encounters a problem, all related operations on Ethereum and the Rollup are immediately and safely rolled back. This completely eliminates the intermediate risks of cross-chain transactions.
Eliminate liquidity fragmentation and let L2s share L1’s deep liquidity pools in real time
If cross-chain operations are not completed within the same block, you have to move funds in advance to pools on each L2 and lock them there, resulting in serious capital inefficiency and liquidity fragmentation.
Within the same Ethereum block, a Rollup can directly “borrow” the deep liquidity of the Ethereum L1 mainnet (such as Uniswap or Aave) at the very moment a call is initiated.
For example, you trigger a transaction on L2, and within the same Ethereum block it directly calls Uniswap on L1 to complete a swap and return the result. To the user, it feels just like operating on a single chain; there is no need to “top up” or move funds between chains in advance.
Avoid state desynchronization and “reorg” attacks
Blockchains can experience reorganizations (reorgs) at any time. If cross-chain transactions are asynchronous and span multiple blocks, Chain A may consider a transaction successful, only for a subsequent reorg on the Ethereum mainnet to erase the upstream state that Chain A relied on. This can cause catastrophic accounting discrepancies.
Requiring everything to be completed within the same Ethereum block means that all state transitions, proof verifications, and proxy callbacks are bound to the same time anchor (the Sync block).
Chains joining the EEZ must abide by an ironclad rule: when Ethereum undergoes a reorg, the chain must roll back in sync. This guarantees at the underlying level that cross-chain states will never become inconsistent due to a “time lag.”
💡 In a nutshell:
Keeping everything within the same Ethereum block means using the blockchain’s most fundamental and robust property—“atomicity”—in place of fragile, time-consuming cross-chain bridges. This lets applications distributed across different L2s share all of the Ethereum mainnet’s liquidity and computational resources instantly and securely, as if they were running on the same CPU core.