Introducing 𝚝𝟷: Unifying Ethereum’s Ecosystem for the Future of Web3

Introduction

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 𝚝𝟷.

𝚝𝟷 protocol diagram
𝚝𝟷 protocol diagram

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]

Subscribe to 𝚝𝟷 (deprecated, use Substack instead)
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.
More from 𝚝𝟷 (deprecated, use Substack instead)

Skeleton

Skeleton

Skeleton