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
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.
Alice creates a transaction (with some fields encrypted to the TEE pubkey), uses her wallet to sign it, and sends it to the ππ· mempool.
A ππ· Sequencer receives and gossips such a partially-blind transaction to other Sequencers in the ππ· Sequencing AVS network.
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.
ππ· 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.
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.
ππ·β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.
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]
Yay:)
Amazing!