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.
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.
ππ· 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.
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.
ππ· 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:
tx broadcast and block sequencing finalization by sequencers (i.e. sequencing consensus),
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 ππ·.
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.
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.
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.
ππ· 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.
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.
ππ·β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.
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.
ππ· 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 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.
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.
ππ· 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]