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

by Can Kisagun, CEO & Co-founder of 𝚝𝟷

For the most up to date thinking on why real-time proving and programmability make t1 a critical building block for Ethereum interoperability, visit “t1 is the cross-chain application infrastructure to enable better web3 UX”.

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 Environment (TEE) 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 lets 𝚝𝟷 read and alter the state of other rollups as part of its own execution and enables 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.

Architecture

Protocol Design

𝚝𝟷 is an EVM-based rollup that generates real-time proofs to provide cross-chain application infrastructure. 𝚝𝟷 combines the verifiable computation guarantees of Trusted Execution Environments (TEE) with additional defense layers such as economic security (AVS) and bespoke zero knowledge proofs (ZKP) to enable fast and secure proof generation. 𝚝𝟷 has two network stakeholders:

• Sequencers are a highly decentralized set of nodes tasked with blindly finalizing the ordering of encrypted transactions in a 𝚝𝟷 block. Since Sequencers only order transactions rather than executing them, we can achieve high decentralization and censorship resistance. Sequencers create Sequencing Consensus

• Executors are TEE-enabled nodes tasked with executing state changes given the finalized sequences of transactions (i.e. blocks) determined by the Sequencers. Executors provide proofs of Execution Consensus.

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

• Tx data broadcast and block finalization by Sequencers (Sequencing Consensus proof)

• Execution and agreement about the new state reached by TEE-enabled Executors (Execution Consensus proof).

Both Sequencing Consensus and Execution Consensus are required to update the state of 𝚝𝟷, including enabling convincing deposit contracts on Ethereum and Partner Rollups to release their funds to withdrawing users. 𝚝𝟷 leverages two networks of EigenLayer Actively Validated Services (AVS) to derive its crypto-economic security from restaked ETH. 𝚝𝟷 also requires bespoke ZKPs for particularly large transactions that would exceed the crypto-economic security budget.

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 network that can meet latency and cost requirements of 𝚝𝟷.

Architecture Diagram

Flow

1. A user Alice deposits funds to a 𝚝𝟷 bridge contract on Ethereum or on a Partner Rollup. Once the deposit is confirmed on the source chain, it gets processed by 𝚝𝟷 and Alice gets her funds credited towards 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. After 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 toPartner 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).

   • 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 submitted 𝚝𝟷 state s, Sequencing Consensus, Execution Consensus and transaction data availability for consistency. If successful, such s is accepted. Alice may now submit to the Canonical Bridge her inclusion proof of the desired withdrawal transaction (as contained within s). The contract then releases the funds to Alice on Ethereum.

8. If Alice wishes to withdraw to her account on a Partner Rollup rather than on Ethereum, the same state update on Ethereum is required as in 7., but the inclusion proof tx is submitted to the bridge contract on Partner Rollup (instead of to Canonical Bridge on Ethereum). The Partner Rollup bridge contract verifies the inclusion proof and then releases the funds to Alice on Partner Rollup.

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.

Ethereum’s contract acts as the Canonical Bridge where 𝚝𝟷 state updates are posted and their validity is ensured by verifying Sequencing Consensus, Execution Consensus and the data availability commitment to a blob posted on Ethereum. Therefore, this contract is the source of truth for 𝚝𝟷 state.

Withdrawals to Ethereum can be enabled immediately right after the transaction updating this contract. Withdrawals on Partner Rollups require the local 𝚝𝟷 bridge contract to check the state of Canonical Bridge on Ethereum before the funds can be released to the user on Partner Rollup. This approach prevents certain attacks that could otherwise result in double-spend.

Sequencers

Sequencers are responsible for broadcasting and ordering (sequencing) partially-encrypted transactions, ultimately forming consensus on such a blind block ordering. The resulting blind block and the accompanying proof of Sequencing Consensus is then propagated to Executors for execution. Since Sequencers don’t execute transactions, 𝚝𝟷 achieves fast Sequencing Consensus with a highly decentralized Sequencer set to provide strong censorship and bribery resistance guarantees. Sequencers order partially-encrypted transactions which eliminates most of ordering-based Maximum Extractable Value (MEV) potential.

𝚝𝟷’s transaction propagation layer is based on Espresso Systems’ Hotshot Consensus. Hotshot consensus is a Byzantine Fault Tolerant (BFT) consensus protocol that is based on Hotstuff BFT and expands it to a Proof-of-Stake (PoS) setting for increased decentralization. 𝚝𝟷 Sequencers (that participate in PoS Hotshot consensus) account for of the two 𝚝𝟷 AVS types. 𝚝𝟷 Sequencing AVS allows Sequencers to lean on restaked stake and includes specific slashing conditions.

Executors

TEE-enabled Executors are responsible for maintaining the most current state of 𝚝𝟷, executing transactions as sequenced into blind blocks by Sequencers and agreeing about the new state. A 𝚝𝟷 Executor is running the t1VM, a TEE-optimized Reth, coming with all the benefits of full Ethereum compatibility. It also maintains an Ethereum full node for communicating with the Canonical Bridge efficiently and contains several Partner Rollup light clients, in order to track the state of such chains without having to rely on (wait for) fraud or ZK proofs. t1VM is enhanced with special opcodes leveraging Reth’s ExEx that allow Executors to query the state of and submit transactions into Ethereum and Partner Rollups from within a 𝚝𝟷 Solidity smart contract.

Executors are using a leader-based instant-finality PoS Byzantine Fault Tolerant consensus algorithm. 𝚝𝟷 Executors account for the second type of 𝚝𝟷 AVS and are subject to slashing.

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]