Today, we are excited to share more about 𝚝𝟷 and our journey. We believe Ethereum should not only be the most decentralized smart contracting ecosystem but also the blockchain with the best user and developer experience. Ethereum best embodies the ethos and values that inspire us about the future of blockchain technology. It has the most decentralized community—a place where the brightest minds gather and innovation thrives. However, the best technology doesn’t always win.

We believe that for Ethereum to provide the best user and developer experience, the rollup fragmentation problem must be solved. The vision of a unified Ethereum ecosystem truly excites us. We started 𝚝𝟷 earlier this year to make this vision a reality.

𝚝𝟷 is a Trusted Execution Environments (TEE) powered rollup that enables real-time proving (RTP) to unify Ethereum and the rollup ecosystem. RTP proves the integrity of 𝚝𝟷 execution to Ethereum in less than 12 seconds to enable instant settlement between 𝚝𝟷 and Ethereum. Moreover, running rollup lightclients in a TEE enables 𝚝𝟷 to read and alter the state of other rollups as part of its own execution, and to enable composability between Ethereum and rollups.

In this post, we’ll do a quick recap of the problem statement and introduce real-time proving and the high-level architecture of 𝚝𝟷’s protocol.

I would like to thank Guy Wuollet, Noah Citron, Joachim Neu, Mike Manning and Orest Tarasiuk for their invaluable feedback and contributions.

The Rollup Fragmentation Problem

While rollups have helped scale Ethereum’s throughput by offloading transactions from the main chain, they have also introduced fragmentation due to siloed execution. Each rollup operates in an isolated way, with its own state and settlement rules. This fragmentation leads to siloed liquidity and breaks composability, making it challenging for users to interact across different applications within the broader Ethereum ecosystem.

Composability would allow decentralized applications (dApps) to interact with one another across rollup chains, creating a seamless experience where users can easily transfer assets and liquidity across platforms. This interconnectedness will be essential to Ethereum’s success, enabling developers to build on existing protocols and enhancing user experience by providing cohesive, frictionless access to financial services

You can read more about the rollup fragmentation issue in our previous post.

Our Mission: Solving the Fragmentation Problem

𝚝𝟷 is a rollup designed to fix liquidity fragmentation and composability challenges in scaling Ethereum. By leveraging AVS-secured TEEs, 𝚝𝟷 introduces real-time proving (RTP) that proves the integrity of 𝚝𝟷 execution to Ethereum in less than 12 seconds. RTP enables instant settlement on Ethereum and, when combined with TEE lightclients, composability across different rollups. 𝚝𝟷’s mission is to solve the rollup fragmentation issue, working towards a vision of a unified Ethereum and rollup ecosystem.

EVM-compatible applications can leverage 𝚝𝟷 to offer low-cost and fast transactions while remaining composable within the Ethereum ecosystem and having access to its users and liquidity. 𝚝𝟷-native applications that utilize 𝚝𝟷’s unique features can innovate within a new cross-chain application design space, enhancing efficiency, security, and user experience.

What Are TEEs and How Do They Help?

Trusted Execution Environments (TEEs) are specialized hardware-based environments that isolate sensitive computations and data from the rest of the system, ensuring that data is processed correctly and privately. In particular, TEEs provide verifiable computation guarantees through  a process called “Remote Attestation”, which proves to external parties that the TEE is running a specific, unmodified piece of software (bytecode) without any tampering. Verifiers can then use this proof to confirm that the TEE and its output is trustworthy. Additionally, TEEs can preserve privacy by keeping sensitive data and execution logic concealed from the system operator and external observers. In other words, TEEs are secure hardware areas that protect sensitive data and computations from tampering or unauthorized access.

Two key requirements for achieving full unification of Ethereum and the rollup ecosystem, without reorg risks and asynchrony at all, are shared sequencing across all chains and real-time proving (RTP). At 𝚝𝟷, we are working on RTP by employing TEEs. However, TEEs also help with cross-chain composability by enabling lightclients in 𝚝𝟷 to reliably read data from and write data to partner rollups. This setup allows 𝚝𝟷 to effectively aggregate the state of Ethereum and partner rollups. Our current design, which does not rely on shared sequencing, enables 𝚝𝟷 to have as low as a single-block asynchrony window (12 seconds) with Ethereum—a substantial improvement over the current seven-day window in Optimistic Rollups and hours-long window in Zero-Knowledge Rollups.

In addition to RTP and cross-chain communication, TEEs allow 𝚝𝟷 to offer an encrypted mempool. An encrypted mempool prevents adversarial reordering, such as sandwich attacks, where an attacker observes a pending transaction and places trades before (front-running) and after (back-running) it, profiting at the expense of regular users. Sandwich attacks cost Ethereum users over $100mn every year [1]. An encrypted mempool also facilitates use cases like sealed-bid auctions and information-incomplete games.

Protocol Design

𝚝𝟷 is an EVM-based rollup that generates real-time proofs to provide a composable cross-chain application infrastructure. It combines verifiable computation guarantees of TEEs with additional defense layers, such as economic security (AVS) and bespoke zero-knowledge proofs (ZKP), all in order to enable fast and secure proof generation. 𝚝𝟷 has two key network stakeholders:

• Sequencers, responsible for sequencing consensus: This highly decentralized set of nodes blindly finalizes the ordering of partially-encrypted transactions in a 𝚝𝟷 block. Since Sequencers only order transactions (rather than executing them), a high level of decentralization is expected, leading to strong censorship resistance while keeping a low latency. Sequencing consensus is backed by Sequencing AVS.

• Executors, responsible for execution consensus: These TEE-enabled nodes calculate the new state of 𝚝𝟷 given the finalized sequence of input transactions (i.e. block contents) determined by the Sequencers. Execution consensus (integrity) is backed by Execution AVS. Moreover, Executors are required to provide a ZKP on top of the regular TEE proof under certain circumstances of increased risk*.*

𝚝𝟷 produces blocks every second. Producing a block involves two sequential steps:

1. tx broadcast and block sequencing finalization by sequencers (i.e. sequencing consensus),

2. execution and consensus by TEE-enabled workers (i.e. execution consensus).

Both sequencing and execution consensus are required to update the state of 𝚝𝟷 canonical bridge smart contract on Ethereum, serving as the ultimate source of truth. Users are only able to withdraw their funds back to their wallet on Ethereum or on partner rollups after the canonical bridge contract state is updated. This process only takes 12 seconds for withdrawals to Ethereum wallets.

As 𝚝𝟷 gradually becomes a fully permissionless network, it’s essential to implement mitigations against potential TEE exploits and develop defense-in-depth strategies. 𝚝𝟷 leverages EigenLayer Actively Validated Services (AVS) to draw crypto-economic security from restaked ETH, therefore providing a programmatic insurance budget of one-third of the staked amount, in addition to TEE guarantees.

However, an attacker controlling more than the crypto-economic security of the Execution AVS stake and the necessary underlying TEEs could produce an acceptable integrity proof for a fraudulent new state of 𝚝𝟷. For this attack to be economically viable, the new state would contain a high value tx that exceeds the slashable AVS stake. To ensure 𝚝𝟷’s economic activity is not bound by the AVS stake security budget, we introduce a bespoke ZKP mechanism as a secondary defense layer: 𝚝𝟷 uses periodic ZKP to create checkpoints. When cumulative tx value since the last checkpoint approaches the crypto-economic security budget or there’s a new very-high-value tx, the protocol requires the creation of another, on-demand ZKP for the canonical bridge to accept such a new state and resume. ZKP generation will likely be outsourced to a verifier network that can meet latency and cost requirements of 𝚝𝟷.

Transaction flow

1. Alice deposits funds to a 𝚝𝟷 deposit contract on Ethereum or on another Rollup. Once Alice’s deposit is confirmed on the source chain, it is processed by 𝚝𝟷 and Alice’s funds credited to her aggregate 𝚝𝟷 balance.

2. Alice creates a transaction (with some fields encrypted to the TEE pubkey), uses her wallet to sign it, and sends it to the 𝚝𝟷 mempool.

3. A 𝚝𝟷 Sequencer receives and gossips such a partially-blind transaction to other Sequencers in the 𝚝𝟷 Sequencing AVS network.

4. Upon receiving transactions for one 𝚝𝟷 slot (1 second), the slot-leading Sequencer proposes an ordering (a blind, non-executed block) and the rest of Sequencers vote on it using Espresso HotShot, to form Sequencing Consensus. This block and a proof of Sequencing Consensus is then passed on to the Execution AVS network.

5. 𝚝𝟷 Executors validate the proof of Sequencing Consensus, decrypt the received block using their TEE private key and execute its ordered plaintext transactions against the current state of the 𝚝𝟷 blockchain. The slot-leading Executor proposes a new state root and the rest of the Executors vote on it to form Execution Consensus.Note: Executors use light clients (also running in TEEs) to read from and write to Ethereum and Partner Rollups if required by a 𝚝𝟷 tx.

6. The Executors post 𝚝𝟷’s new state and the corresponding consensus proofs to the Ethereum 𝚝𝟷 Canonical Bridge contract and the full (yet compressed) plaintext transactions to Ethereum Blob DA. This generally facilitates withdrawals from 𝚝𝟷 to Ethereum with a single-Ethereum-block delay only (6 seconds on average).

   Note: In the rare event that the new states’ cumulative value since the last ZKP checkpoint is approaching the crypto-economic security budget provided by Execution AVS, also an ad-hoc ZKP is required by the Canonical Bridge, pausing finalization until then; this increases the withdrawal delay to hours. In addition, 𝚝𝟷 periodically generates and post ZKPs to the Canonical Bridge on Ethereum to create checkpoints and speeding up the ad-hoc ZKP creation when required by the above criterion.

7. 𝚝𝟷’s Canonical Bridge contract on Ethereum checks the new 𝚝𝟷 state s, transaction data availability and Sequencing Consensus alongside Execution Consensus proofs for consistency. If successful, such s is accepted and Alice may now submit her final transaction on Ethereum that presents the Ethereum 𝚝𝟷 canonical bridge contract with an inclusion proof of her withdrawal transaction that was contained within the newly accepted s. The contract then releases the funds to Alice on Ethereum.

8. Similar to 7., non-Ethereum withdrawals (withdrawals on a Partner Rollup) require Alice to submit her final transaction on the partner rollup bridge contract with an inclusion proof of her withdrawal transaction that was contained within the newly accepted s. Rollup deposit contract checks that the 𝚝𝟷 Canonical Bridge contract on Ethereum to have accepted the new state first before releasing funds to Alice.

Bridge Contracts

𝚝𝟷 leverages its contracts on Ethereum and rollups to accept deposits into 𝚝𝟷 and allow users to withdraw funds from 𝚝𝟷 back to their blockchain of choice.

The deposit contract on Ethereum serves as the canonical bridge where 𝚝𝟷 state updates are posted and validated, making it the source of truth for 𝚝𝟷 state. Withdrawals to Ethereum can be enabled immediately right after the transaction updating this contract. Withdrawals on Rollup require the Rollup 𝚝𝟷 contract to check the state of the 𝚝𝟷 canonical bridge contract on Ethereum before releasing funds to users. This design prevents certain attacks that can result in double-spend.

Sequencers

Sequencers are responsible for broadcasting and ordering (sequencing) transactions, and forming consensus on the ordering of partially-encrypted transactions before the blocks are propagated to executors for execution. Since sequencers do not execute transactions, 𝚝𝟷 can achieve fast sequencing consensus with a highly decentralized sequencer set, providing strong censorship and bribery resistance. Sequencers order partially-encrypted transactions which eliminates most of the ordering-based Maximum Extractable Value (MEV) potential.

𝚝𝟷 sequencers will leverage Hotshot Consensus built by Espresso Systems. Hotshot consensus is a Byzantine Fault Tolerance (BFT) consensus protocol that is based on Hotstuff BFT and expands it to a Proof-of-Stake (PoS) setting to enhance decentralization. 𝚝𝟷 sequencing consensus will be secured by restaked ETH from EigenLayer AVS. Malicious sequencers will be subject to having their stake slashed.

In the future, 𝚝𝟷 blocks may be constructed by shared sequencers including based sequencing, enabling universal synchronous composability between 𝚝𝟷 and participating networks.

Executors

TEE-enabled executors are responsible for maintaining the 𝚝𝟷’s state, executing transactions sequenced into blocks by the sequencers, and reaching on the new state. A 𝚝𝟷 executor operates TEEVM, a TEE-optimized Reth, which provides all the benefits of full Ethereum compatibility. TEEVM also includes Helios, an Ethereum light client for efficient communication with the canonical bridge efficiently. TEEV also contains several rollup full nodes, in order to track the rollup states without waiting for fraud or ZK proofs. Enhanced with specialized opcodes leveraging RethExEx, TEEVM allows executors to query the state and submit transactions across Ethereum and partner rollups.

Executors use a leader-based instant finality PoS Byzantine Fault Tolerance consensus algorithm. 𝚝𝟷 executors are the second type of 𝚝𝟷 AVS and are subject to slashing, ensuring accountability.

Conclusion

𝚝𝟷 addresses fragmentation and composability challenges in the Ethereum ecosystem by innovating on real-time proving (RTP) with a network secured by TEEs, AVS and bespoke ZKPs. This architecture, designed with defense-in-depth in mind, allows instant settlement back to Ethereum under  almost all circumstances while remaining resistant even against adversaries controlling a large restaked stake. We believe this is a practical and solution-oriented approach that addresses the rollup fragmentation issue today.

If you’re excited about fixing Ethereum’s fragmentation problem, join us in this journey! Follow us on Twitter @𝚝𝟷protocol for the latest updates, insights and community discussions.

Are you a developer eager to get early access to our codebase and willing to help shape the future of Ethereum’s composability? Or perhaps you’re a passionate community member who wants to contribute to growing the 𝚝𝟷 ecosystem? Fill out this form, and we’ll be in touch soon.

Let’s build the future of Ethereum together!

Can Kisagun

Resources

[1] EigenPhi, “MEV Sandwich Attacks on Ethereum,” EigenPhi.io. [Online]. Available: https://eigenphi.io/mev/ethereum/sandwich. [Accessed: Oct. 24, 2024]

I would like to thank Dankrad Feist, Justin Drake, Noah Prevecek, Murat Akdeniz, Guy Wuollet, Mike Manning and Orest Tarasiuk for their valuable feedback!

The Evolution of Ethereum and Scaling Solutions

Ethereum has been at the forefront of blockchain technology, serving as the foundational infrastructure layer for decentralized finance (DeFi), non-fungible tokens (NFTs), and countless decentralized applications (dApps). However, as the Ethereum network has grown, so too have its scalability challenges, paving the way for alternative Layer 1s and rollups.

During the DeFi summer of 2020, we experienced the explosive growth of decentralized finance (DeFi) protocols like Uniswap, Compound, and Aave as DeFi grew from a $600mn to a $15bn ecosystem within a year [1]. Often referred to as “Money Legos”, these applications that run in the same execution environment all work in a composable manner, interacting and integrating with each other like building blocks. This composability property allows users to combine various financial services such as lending, borrowing and trading, enabling unprecedented innovation in dApps. However, this tremendous growth of DeFi also led to a dramatic surge in Ethereum gas costs. The network’s capacity was stretched as the average gas price skyrocketed from around 10-20 Gwei earlier in the year to over 100 Gwei, leading to transaction costs going well over $100 [2]. As a result, many smaller users were priced out of Ethereum, highlighting the scalability challenges Ethereum faced at the time. This created an opportunity for EVM-compatible alternative L1s like Binance Smart Chain and Polygon to emerge as a new home for developers to deploy low-cost applications and attract otherwise priced-out smaller users.

Ethereum introduced the rollup-centric scaling roadmap in October 2020 to increase transaction throughput without compromising on decentralization or security [3]. The rollup-centric approach leverages Ethereum’s inherent security while enabling high throughput. By allowing rollups to execute transactions off-chain and using the base layer for secure data availability and settlement, Ethereum promised to keep up with with alternative L1s, which often face challenges maintaining decentralization and security as they scale. Rollups also provide a new design space for innovation; developers can experiment with new VMs, mechanism designs or other primitives to provide superior experience and capture market share.

The Rollup Fragmentation Problem

While rollups are able to scale Ethereum, they also introduce fragmentation. There are two main reasons behind this fragmentation: The first is siloed execution across different rollup ecosystems and the second is long proving or settlement times on L1 [4].

Siloed Execution

Rollups and Layer 2s are execution silos. They each have their own state, sequencing rules and settlement methods. As a result, applications are only composable within a given rollup stack and completely disconnected from the rest of the Ethereum ecosystem. This leads to liquidity and a broader composability fragmentation, which are detrimental to the experience of Ethereum user and developers:

• Liquidity pools on one rollup are inaccessible to users of another rollup, which reduces the efficiency of DeFi markets.

• More broadly, applications on one rollup are not aware of the state of applications in other rollups and cannot make calls to (interact with) them.

Slow Settlement

Settlement (e.g. withdrawals) on Ethereum requires rollup execution to be verified on Ethereum. This introduces a latency which we call finality or settlement latency. Currently, optimistic rollups have a 7-day settlement latency due to fraud proofs and zero-knowledge rollups have a settlement latency on the order of hours [5].

In essence, rollup fragmentation is akin to the problem of walled gardens in Web2. Users and developers are vendor-locked-in into isolated ecosystems, leading to a suboptimal user and developer experience, as well as limited network effects.

How Is Rollup Fragmentation Impacting Us?

Let’s look at how fragmentation is impacting users as well as application and rollup developers.

Users

As a part of the rollup-centric scaling roadmap, Ethereum expects most of the usage to go to rollups. However, this is not the case today. Only 13% of active Ethereum users (EOAs or Externally Owned Accounts which are essentially user wallets on Ethereum) have also been actively using one of the 6 major rollup ecosystems in the last 30 days; on average 5.68mn EOAs were active on Ethereum per day, of which only 723K were active on at least one rollup [6]. While EOA-based and Ethereum-as-entrypoint-conditioned user analysis has its limitations, it’s also the best metric we have. Based on this; most Ethereum users are not using rollups. Rollups, while playing an important role in scaling Ethereum, are not serving the majority of Ethereum users yet.

Note that during the same period a total of 27mn EOAs were active on the mentioned rollups above.

Bridging problems

One thing we know for sure is that the bridging experience does not help the adoption of rollups. Assets on rollups can either be bridged by the canonical rollup bridge, by using external cross-chain messaging protocols like LayerZero or Chainlink CCIP or minted natively on the rollup like USDC or rollup native tokens.

Most assets on rollups are bridged using the canonical bridges. For example, of $13.20bn TVL on Arbitrum, approximately $10.55bn TVL is driven by Ethereum native assets (excluding ARB, Arbitrum native tokens or tokens from alternative L1s like BSC). Of the Ethereum native assets, 80% are bridged via the canonical bridge, 14% of assets native to Ethereum are minted on Arbitrum and 6% is bridged via external bridges. [7]

However, as mentioned earlier, canonical bridges introduce latency in Ethereum settlement. In order for fast withdrawals back to Ethereum to happen, users need to rely on third party liquidity-pool bridges or RFQ bridges. Liquidity-pool bridges are deposit contracts on chains that are controlled by a handful of entities, mostly using multisig wallets. If Alice wants to withdraw WBTC from Arbitrum to Ethereum, Alice deposits WBTC to the bridge contract on Arbitrum and she can withdraw WBTC on Ethereum given there’s enough WBTC on the liquidity-pool of the bridge on Ethereum. Once assets are bridged via the canonical contract they can be deposited on liquidity-pool bridges.

The cross-chain transfers these bridges can facilitate are capped by the deposits they have on the destination chain. If we look at the top 3 liquidity-pool bridges on Ethereum by TVL; Wormhole (Portal) [8], Axelar [9] and Stargate [10] collectively have approximately 96.5K ETH deposits. The amount of ETH deposited on the Arbitrum canonical bridge contract alone is approximately 1.28mn ETH or 13x the ETH TVL of top 3 liquidity-pool bridges on Ethereum [7]. The amount of ETH deposited on the 6 rollups analyzed above via canonical bridges is 2.6mn. Less than 4% of this amount can be bridged within a couple of minutes via liquidity-pool bridges given low deposits. The main reason users don’t deposit funds on liquidity-pool bridges is because it’s very risky. The liquidity-pool bridges have been exploited and lost billions of dollars. While the deposit amounts may be low, these bridges are efficient under normal circumstances, as they aggregate liquidity net transfers against each other. Major liquidity bridges have 3-4x monthly volume compared to their TVL [20]. However in black swan events, these bridges impose limitations on individual transfer amounts. Larger withdrawals require longer processing times and higher fees. I was using Wormhole during the Terra collapse to get UST out to Ethereum and convert it to USDC. The transfer took hours, during which UST lost a significant amount of value.

A safer alternative to liquidity pool bridges are intent based RFQ (request for quote) bridges. RFQ bridges replace the reliance on liquidity pools with market makers or solvers. These market makers provide Alice funds on the destination chain and receive Alice’s funds on the source chain. Across is emerging as the winner in this space. This model relies on market makers charging fees to cover for their cost of capital, which get significantly high with larger operations.

An unspoken fact in bridging funds between different ecosystems is the use of centralized exchanges. Market makers have a very high cost of capital compared to retail users. As a result, fast bridging is extremely important to them, not because of superior UX or cross-chain application composability but because bridging time actually impacts their return on capital. Interviews with market makers consistently imply that most market makers heavily rely on centralized exchange bridges to move funds between Ethereum and rollups.

UX problems

Users who don’t want to pay L1 fees not only decide what application to use but also need to decide which rollups to interact with. The process of choosing a rollup from Metamask is a significant UX friction. When we call an Uber, we care about getting to our destination, not about whether Uber’s backend runs on AWS or on GCP. As we are trying to reach a billion users, we have to provide better UX.

Developers

Fragmentation is an equally big issue for cross-chain applications. Most DeFi protocols deploy on different chains to meet the user demand, without a cohesive cross-chain product strategy. Applications on different chains feel different to the users. AMMs with deeper liquidity provide better execution to its users. AMM liquidity varies between different rollups: Uniswap has the deepest liquidity pool for the WETH/USDC pair on Ethereum. However on Base, Aerodrome offers the most liquid WETH/USDC pool. This is not good for users as they need to navigate which AMM gives them the best execution in each rollup.

In an ideal world, the experience of a given application should not depend on the infrastructure behind the instantiation of such an application. Most cross-chain teams spend significant amounts of time maintaining different deployments in different chains rather than focusing on shipping innovative features that would allow them to provide more value to users.

Recently, several Ethereum applications such as Frax, Aevo (formerly Ribbon Finance), Synthetix and Uniswap have launched or announced plans to launch their own rollup. These teams face the trade-off between providing low-cost transactions and enabling composability with the rest of the Ethereum ecosystem. Given these applications are Ethereum-native and their users are mostly on Ethereum, losing composability with the Ethereum application ecosystem is a significant friction. When we look at Frax Finance, only $12mn of the $470mn TVL is on Fraxtal, the rollup built by FRAX, while 95% of the TVL is on Ethereum [11]. In an ideal world, interacting with a low transaction cost version of your favorite app should feel like interacting with just another smart contract on Ethereum. And you shouldn’t even know about it.

Finally, application developers who are building new products on rollups are required to make a bet on the success of that specific ecosystem. While it’s possible to deploy to several rollups, in an ideal world, application developers should be betting on the success of Ethereum rather than that of a set of individual rollups.

Rollup liquidity

While rollups provide an environment for permissionless innovation and experimentation with new primitives, it’s really difficult for them to bootstrap liquidity. Lengthy withdrawal time creates a significant friction for users and TVL becomes a moat. It’s important for a rollup to attract liquidity because DeFi applications require liquidity to function effectively. Even with the strong brand of Frax, Fraxtal has struggled to attract non-Frax (FXS, FRAX etc.) assets to the rollup [11]. The friction in bootstrapping liquidity makes it very difficult for rollups to innovate and provide a great UX. Most rollups therefore resort to airdropping tokens (directly or through ecosystem applications) to attract liquidity which in most cases is mercenary, unsustainable capital.

Overall, fragmentation creates significant issues for all stakeholders involved in the ecosystem. As long as Ethereum liquidity and users are fragmented, Ethereum’s network effects are diminished.

The Endgame…

The ideal end state for Ethereum and the rollup ecosystems is one where everything feels as a single unified ecosystem with low-cost transactions. To achieve this, we need to achieve Universal Synchronous Composability, a term coined by Justin Drake. Universal Synchronous Composability means that applications across different rollups should be able to work together seamlessly and in real-time. To be more precise, a smart contract on rollup A can call a function on smart contract on rollup B and learn the outcome of that call, all in the same block. Let’s unpack this a little bit [4].

Blockchains, which are state machine replication systems, function when participating nodes agree on i) the ordering of transactions and ii) the state after the agreed-upon transactions are executed. When we apply this to the definition of Universal Synchronous Composability, we need both;

• A smart contract on rollup A can call a smart contract on rollup B, in the same block: This requires blocks to be sequenced by the same entity or entities that somehow form consensus on the ordering in the block for both rollup A and rollup B.

• A smart contract on rollup A can learn the outcome of the contract call initiated on rollup B, in the same block: This requires rollup A to either execute transactions for rollup B, or to verify a proof of execution integrity of rollup B [12].

In order to achieve Universal Synchronous Composability, we need to have shared sequencing and real-time proving. Real-time proving is the ability to prove state transitions in a rollup within one base layer block, which is 12 seconds for Ethereum. Real-time proving allows rollup deposits to be withdrawn immediately (real-time settlement).

Rollups today have only centralized, siloed sequencers, and are highly asynchronous, with a 7-day and hour(s)-long latency for optimistic and zero-knowledge rollups, respectively.

While Universal Synchronous Composability really gives superpowers to blockchains, it’s important to remember that the internet is asynchronous. The Internet is not synchronous, but is extremely fast. As a result, we don’t observe a problem with its asynchrony. There are prominent voices like Vitalik Buterin, who believe synchronous composability is overrated [13]. If our aim is to provide Web2.0 level UX, then low latency is sufficient for us to restore a unified UX for Ethereum.

And how to get there!

Earlier, we established that we need both shared sequencing and real-time proofs to achieve Universal Synchronous Composability. Let’s take a quick deep-dive into these areas:

Shared sequencing

Shared sequencing networks allow rollups that opt-in for shared sequencing to have their blocks be sequenced (built) by the same entity during a specific time period. Such a builder therefore has monopoly power over ordering transactions across multiple rollup ecosystems and can thus provide guarantees on including cross-domain transactions (e.g. contract interactions).

Shared sequencing networks introduce an auction model, which requires builders to bid for sequencing rights, usually above a reserve price set by the rollup operator. In this model, shared sequencers are going to be able to bid above the reservation price when there are cross-chain MEV opportunities that individual rollup sequencers cannot tap into. Users can pay shared sequencers a premium for cross-chain composable transactions. As more users demand cross-chain bundles rather than single rollup transactions, the revenue potential of centralized sequencers, that can only serve users in a single rollup, will go down, making it easier for shared sequencers to bid competitively. Shared sequencing will also be profitable in blocks where there is significant cross-chain MEV. The MEV opportunity has to either come from CEX-DEX arbitrage during times of high volatility or from a builder-favorable ordering (yes, including sandwich attacks!), which is a practice that current centralized non-shared sequencers do not engage in.

Based sequencing with pre-confirmations

In order to extend synchronous composability from only between rollups to also include Ethereum, more work is needed. This goal can be achieved by having Ethereum proposers (or builders, in reality) also serve as builders in a shared sequencer model for the rollup ecosystem.

In this scenario, Ethereum proposers, who are selected for a slot of 12 seconds, also have sequencing (ordering) rights for all participating rollups. However, such a window of 12 seconds is too slow for rollups as they need to provide much faster “soft confirmations” to their users. As a result, we’d need to introduce “pre-confirmations” (aka “preconfs”), i.e. commitments from the L1 proposer to sequence and include certain rollup transactions in sub-Ethereum block time. These out-of-protocol pre-confirmations require the proposer to provide a stake (a slashable collateral). Initial discussions for the stake amount of these builders range around 1000 ETH [14]. EigenLayer AVS, the dominant Ethereum restaking provider currently has 76 operators that has more than 1000 restaked ETH [15]. In addition to high collateral requirements, these cross-domain builders will need to have high bandwidth, high uptime and low latency. These requirements will be a centralizing factor.

Real-time proof generation

Traditional real-time proving requires the ability to create a SNARK (Succinct Non-interactive ARgument of Knowledge) or STARK (Scalable Transparent ARgument of Knowledge) within an Ethereum slot’s duration (i.e. 12 seconds). Such constructs are cryptographic “proofs” that ensure the validity of an execution trace, e.g. the state transition in the case of zero-knowledge rollups. Currently, STARKs and SNARKs are costly and take a long time to produce off-chain, and are expensive to verify on-chain. Scroll, the largest ZK rollup in terms of TVL, currently posts such a proof only once an hour [16] and proof verification accounts for ~75% of their on-chain costs [17]. While there’s progress with hardware acceleration, ASICs etc., we don’t expect such traditional real-time proof generation to be large-scale viable in the next few years.

One idea that’s been proposed by Justin Drake is to use liquidity providers and solvers who would take the risk of execution faults to provide loans to users [18]. However, as discussed earlier, such market makers or solvers would need to charge users for their risk and cost of capital, rendering such an approach a band-aid solution only.

Another alternative to STARK/SNARK real-time proof generation is via Trusted Execution Environments (TEE). Such TEEs are designed to be secure areas within processor hardware able to run code. TEEs guarantee that the code and data running inside the TEE cannot be tampered with. TEEs provide cryptographic proofs (“remote attestation”) to verify that the code they’re running  is genuine and untampered. Any changes or unauthorized modifications to the TEE break the remote attestation and would be detected. However, while TEEs have extremely valuable properties, they have been exploited in the past [19]. Whether for privacy or for verifiable compute, we must therefore reinforce them with defense-in-depth strategies.

How 𝚝𝟷 contributes to the endgame?

𝚝𝟷 is a rollup designed to address fragmentation and composability challenges in the Ethereum ecosystem. By leveraging AVS-secured Trusted Execution Environments (TEEs), 𝚝𝟷 introduces real-time proofs (RTP) that prove the integrity of 𝚝𝟷 execution to Ethereum in less than 12 seconds. RTP allow instant settlement on Ethereum and composability across different rollups. While this composability is NOT fully synchronous, 𝚝𝟷 provides a single-block asynchrony window, which we believe is acceptable while we as Ethereum community work on longer-term solutions.

Conclusion

In this post, we’ve explored the challenges of rollup fragmentation within Ethereum and its effects on users, developers and the broader ecosystem. Rollups, while essential in scaling Ethereum, have led to liquidity fragmentation and have broken composability across applications, limiting the network’s full potential. The ultimate goal for Ethereum is to achieve a unified, composable ecosystem where users can interact with different applications seamlessly across rollups. To get there, the focus must be on introducing some type of shared sequencing as well as making real-time proof generation feasible.

At 𝚝𝟷 𝚙𝚛𝚘𝚝𝚘𝚌𝚘𝚕, we are addressing the latter. Our mission is to unify Ethereum and the broader EVM rollup ecosystem, ensuring the scalability and composability needed for Ethereum to thrive. We believe TEEs are a practical solution to address a critical problem that exists today.

For more insights on Ethereum’s rollup fragmentation and how 𝚝𝟷 is addressing it, follow us on Twitter. We are actively seeking to collaborate with application developers and rollup builders for a more composable Ethereum ecosystem. If you share our excitement about this being a problem worth solving, get in touch with us today!

References

[1] "DeFiLlama," [Online]. Available: https://defillama.com/. [Accessed: Oct. 7, 2024].

[2] "Etherscan Gas Price Chart," [Online]. Available: https://etherscan.io/chart/gasprice. [Accessed: Sep. 30, 2024].

[3] V. Buterin, "A Rollup-Centric Ethereum Roadmap," Ethereum Magicians, Dec. 2020. [Online]. Available: https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698. [Accessed: Sep. 20, 2024].

[4] J. Drake, “Comment on ‘Ethereum 2.0: The Road to Proof-of-Stake’,” Reddit, Mar. 21, 2023. [Online]. Available: https://www.reddit.com/r/ethereum/comments/191kke6/comment/kh78s3m/. [Sep 25, 2024]

[5] “L2 Risks,” L2Beat. [Online]. Available: https://l2beat.com/scaling/risk. [Accessed: Oct 2, 2024].

[6] M. Glinka, “Dune Analytics Query 3752807,” Dune. [Online]. Available: https://dune.com/queries/3752807?days_in_scope_t6c1ea=10&window_length_t6c1ea=30. [Accessed: Oct 5, 2024]M. Glinka, “Dune Analytics Query 3984338,” Dune. [Online]. Available: https://dune.com/queries/3984338?days_in_scope_t6c1ea=10&window_length_t6c1ea=30. [Accessed: Oct 5, 2024]

[7] “L2BEAT - Arbitrum TVL Breakdown,” L2BEAT. [Online]. Available: https://l2beat.com/scaling/projects/arbitrum/tvl-breakdown. [Accessed: Oct 13, 2024].

[8] “Wormhole: Portal Token Bridge - Multichain Portfolio,” Etherscan. [Online]. Available: https://etherscan.io/address/0x3ee18B2214AFF97000D974cf647E7C347E8fa585#multichain-portfolio. [Oct 13, 2024].

[9] “Axelar Gateway - Multichain Portfolio,” Etherscan. [Online]. Available: https://etherscan.io/address/0x4F4495243837681061C4743b74B3eEdf548D56A5#multichain-portfolio. [Oct 13, 2024].

[10] “Stargate Finance - Pool,” Stargate Finance. [Online]. Available: https://stargate.finance/pool. [Oct 13, 2024]

[11] “Frax Finance - Protocol Information,” DeFiLlama. [Online]. Available: https://defillama.com/protocol/frax-finance#information. [Accessed: Oct, 11, 2024].

[12] “We’re All Building the Same Thing,” DBA.xyz. [Online]. Available: https://dba.xyz/were-all-building-the-same-thing/. [Accessed: Oct 6, 2024].

[13] V. Buterin, “A lot of people forget this, but the reason why DAOs are interesting is because they are efficient, not because they are a legal entity. They enable large-scale cooperation that is not feasible with existing systems,” X (formerly Twitter), Feb. 27, 2022. [Online]. Available: https://x.com/VitalikButerin/status/1803459217933623418. [Accessed: Oct 6, 2024].

[14] D. Hoffman, R. Cooper, and J. Drake, "Fragmentation: The Future of L2s and Rollups," Bankless, Jun. 27, 2022. [Online]. Available: https://www.bankless.com/fragmentation. [Accessed: Sep. 25, 2024].

[15] “EigenLayer Operator Dashboard,” EigenLayer, [Online]. Available: https://app.eigenlayer.xyz/operator. [Accessed: Oct. 15, 2024].

[16] “Liveness,” L2Beat, [Online]. Available: https://l2beat.com/scaling/liveness. [Accessed: Oct. 13, 2024].

[17] “Scroll Onchain Costs,” L2Beat, [Online]. Available: https://l2beat.com/scaling/projects/scroll#onchain-costs. [Accessed: Oct. 15,2024].

[18] J. Drake, “Ethereum Sequencing and Preconfirmations Call #6,” YouTube, Apr. 12, 2024. [Online]. Available: https://www.youtube.com/watch?v=w91otDFmGpo&t=343s. [Accessed: Sep. 21, 2024].

[19] “SGX.Fail” [Online]. Available: https://sgx.fail/. [Accessed: Sep. 30, 2024]

[20] “Bridge Volume on Ethereum,” DefiLlama.com [Online]. Available: https://defillama.com/bridges/Ethereum. [Accessed: Oct. 16, 2024].”