SevenX Ventures: What cutting-edge infrastructure is needed for a multi-Rollup world?
TechFlow Selected TechFlow Selected
SevenX Ventures: What cutting-edge infrastructure is needed for a multi-Rollup world?
This article will delve into the four fundamental pillars shaping the future of multi-Rollup ecosystems.
Navigating Web3 tides with focused insightsAuthor: Grace, SevenX
A clear trend has recently emerged: an increasing number of dApps are announcing their own Rollup applications. Additionally, the number of upcoming general-purpose Rollups continues to grow.
As transaction volume and the number of dApps continue to rise, Ethereum faces scalability challenges, prompting the emergence of general-purpose Rollups. These Layer 2 solutions process more transactions off-chain and then securely record them on the main chain, perfectly balancing scalability and security. The versatility of Rollups supports a wide range of dApps, eliminating the need for each application to have its own unique scaling solution.
Application-specific Rollups are tailored solutions designed to meet the unique needs of individual applications, enhancing speed by optimizing transaction processing for specific use cases. In terms of cost, this type of Rollup may offer a more efficient alternative, especially valuable during network congestion. A key advantage of Rollups is flexibility. General-purpose Layer 2 solutions tend to be rigid and constrained by EVM design, whereas application-specific Rollups can be customized—making them ideal for applications like gaming that require specific precompiles. Furthermore, Rollups help dApps capture value more efficiently and gain stronger control over tokenomics and revenue streams.
As consensus grows around the widespread adoption of Rollup technology, looking ahead to the coming year, multiple Rollups are expected to dominate the market. Therefore, the top priority is building robust infrastructure to serve as the "reinforced concrete" foundation.
This article will delve into the four fundamental pillars shaping the future multi-Rollup ecosystem:
-
Security Foundation: The security layer is the cornerstone of trust in the decentralized world. This section explores the critical role of the security layer in ensuring the integrity of Layer 2 transactions, establishing trust assumptions, and addressing potential security risks.
-
Balancing Customizability and Interoperability: Seamless interoperability between different Rollups is key in a modular blockchain world. This section dives into the interoperability challenges introduced by modular architectures and discusses how to address fragmentation and build a cohesive ecosystem.
-
Cost Analysis: Lowering costs is essential for Rollup mass adoption and viability, as it reduces economic barriers compared to smart contracts. Rollup cost efficiency is primarily achieved in two ways: aggregating with other Rollups to share costs and achieve economies of scale, or delegating certain tasks to external service providers to enable division of labor.
-
Shared Security: Shared security layers are indispensable because they reduce the time and resources required to secure new protocols or modular layers, enabling them to achieve strong security comparable to mature platforms like Ethereum. Numerous solutions already exist, such as Eigenlayer, Babylon, Cosmos’ ICS, and Mesh Security.
These four aspects together form a comprehensive blueprint driving the development of infrastructure necessary for a thriving, cohesive modular blockchain world.
Security Foundation
Trust and security lie at the heart of all decentralized systems. Without trust and security, a trustless ecosystem becomes unsustainable. The security layer is crucial; without it, users and total value locked (TVL) are exposed to risk. Plasma and sidechains were once seen as saviors for Ethereum’s scalability, but their decline served as a warning. Issues such as “data availability” undermined trust, ultimately resulting in user losses. Given this context, we begin our discussion with the security layer.
To understand the complexity of Rollups and their potential vulnerabilities, it is essential to dissect the lifecycle of a Layer 2 transaction. Taking a smart contract Rollup as an example, we will examine each stage, identifying trust assumptions and potential security risks:
Submitting transactions via RPC:
-
Trust assumption: The RPC endpoint is reliable and secure. Users and dApps currently trust RPC providers such as Alchemy and Infura.
-
Security issues: Users may face censorship from RPC providers—for instance, Infura and Alchemy blocking RPC requests to Tornado Cash. RPC providers may also suffer DDoS attacks, as demonstrated by ANKR's DNS hijacking incident.
-
Solutions: RPC providers like Infura are actively advancing decentralization roadmaps. Additionally, users can opt for decentralized alternatives such as Pocket Network.
Sequencer orders transactions, providing pre-commitment: insecure state
-
Trust assumption: Users assume the sequencer fairly orders transactions and provides truthful pre-commitments.
-
Security issues: The system must resist censorship and ensure unbiased transaction processing. It must remain operational at all times and ideally prevent sequencers from extracting malicious maximum extractable value (MEV) at the expense of end users.
-
Solutions: Censorship Resistance (CR) and Liveness: Based on censorship resistance and liveness, current solutions rank (from low to high): single sequencer → POA → permissionless POS sequencer → shared sequencer → Rollup-based (ordered at Layer 1). Note that POA with limited authority and no forced transaction support may exhibit lower censorship resistance than centralized sequencers with forced txn enabled.
Regarding liveness, another key metric to consider is proposer failure—the scenario where the proposer goes offline. In such cases, users must still be able to withdraw funds.
- Even if the sequencer is censoring or refusing to work, some Rollups allow users to submit transactions directly to Layer 1 themselves—emergency exits (the validity of forced transactions depends on implementation). However, this approach may be too costly for users with limited funds, and users may desire constant censorship resistance and liveness.
- Some Rollup solutions, such as Arbitrum and Fuel, allow anyone to become a proposer after a certain delay period—self-proposing.
- Review metrics for each Rollup.
-
For more details on various solutions, refer to my previous thread.
MEV Protection:
-
Different privacy solutions can help protect users from frontrunning or sandwich attacks by hiding transaction data (which also enhances censorship resistance). Methods for concealing transaction information include FCFS with private mempools (currently implemented by Arbitrum and Optimism), SUAVE’s TEE solution, and threshold encryption (being researched by Shutter Network). The more complex the solution, the simpler the transaction computation becomes.
-
It should be noted that the goal is MEV protection, not elimination. Research by @tarunchitra summarizes two main directions for reducing MEV: reducing miners' flexibility in reordering transactions through enforced ordering rules, and introducing competitive markets for reordering, adding, and/or censoring transactions. However, the study concludes that neither fair ordering nor economic mechanisms alone can effectively reduce MEV across all payment functions. In some cases, MEV cannot be entirely eliminated.
When economically feasible, the sequencer executes and publishes transaction batches and state roots to the Data Availability (DA) layer; secure state
-
Trust assumption: Block producers publish entire blocks to the DA layer for others to download and verify.
-
Security issues: If part of the data is unavailable, blocks may contain malicious transactions hidden by block producers. Even if transactions are non-malicious, hiding them could compromise system security. The sequencer must have access to transaction data since Rollups need to know network states and account balances.
-
Solutions:
Currently, publishing data on Ethereum is the safest but most expensive option (after proto-danksharding, costs will drop by 90%, but even with 10x throughput, it may still fall short for Rollups): all Ethereum nodes can download and broadcast Rollup transactions. Because Ethereum has extensive node replication and transaction data verification, data is unlikely to disappear or become completely unavailable.
- After danksharding, Ethereum nodes won’t download all transaction data but instead use DAS and KZG to sample only portions (similar to Avail’s solution mentioned below).
- According to modular principles, posting Rollup transaction data to a dedicated Data Availability layer might be more efficient (Ethereum’s theoretical performance may be slightly worse because, besides data availability, Ethereum still retains Layer 1 execution—see comparison between EigenDA and Ethereum below).
Current modular data availability solutions require trade-offs between security and performance. It’s difficult to compare DA security using just one dimension:
- Avail and Celestia use DAS to ensure data availability; with sufficient sampling, data is secure. Since data unavailability can be easily detected and recovered by a small fraction of light clients, light clients can sample and largely guarantee data availability. Without DAS, this wouldn't be possible. The degree of decentralization of the DA layer—i.e., the number of nodes in the network—determines the security level and distribution of incentives. EigenDA doesn’t use DAS but instead employs a custody proof mechanism to prevent restakers from slacking. In other words, DA operators must regularly compute a function that can only be completed after downloading all required data. If blob proofs are incorrect, penalties apply (though storage isn’t required after proof completion).
- Ensuring accuracy of the data replication process (i.e., erasure coding). EigenDA, post-EIP-4844 Ethereum, and Avail use KZG commitments for accuracy, which require substantial computation. Celestia uses a fraud-proof-based design. Light nodes must wait a period before confirming a block has been correctly encoded, achieving finality from their perspective. (* If validity proofs are a better trade-off, Celestia may switch to validity proofs.)
- Economic security of the DA layer (reorg and collusion risks): Depends on staked value within the DA layer, i.e., 2/3 of staked value in Avail and Celestia.
- Forwarding DA layer’s data availability certificates to Ethereum. If data is published to another DA layer while settlement contracts remain on Ethereum, a bridge contract is needed to verify DA availability for final settlement.
-- Celestia’s Blobstream verifies signatures on data availability proofs from Celestia. This proof is a Merkle root of Layer 2 data signed by Celestia validators, proving data is available on Celestia. This feature is now live on testnet.
-- Avail uses an optimistic method to verify data availability proofs. Once published to an Ethereum bridge contract, a challenge period begins, during which the proof is considered valid unless contested.
-- Succinct is collaborating with Avail and Celestia to develop zk-SNARK-based data proof bridges, making verification more secure and cheaper through zk proofs.
-- For EigenDA, dispersers split tasks and publish them to EigenDA nodes, then aggregate signatures and relay data to Ethereum.
Final Settlement: Finalized State
-
Trust Assumption 1:
Once the first valid Rollup block is published on the main chain, Rollup full nodes (nodes capable of fully computing state without relying on other proofs) can finalize it at their height, as they possess the necessary data and computational resources to quickly verify block validity. However, this is not the case for third parties like light clients, which rely on validity proofs, fraud proofs, or dispute resolution protocols to verify state trustlessly without running a full chain replica.
-
Security Issue 1:
For ZK Rollups, Layer 1 verifies zero-knowledge proofs and accepts only correct state roots. The main difficulty lies in the cost and generation process of zero-knowledge proofs. On the other hand, Optimistic Rollups rely on the premise that at least one honest party will promptly submit a fraud proof to challenge any malicious transaction. However, most current fraud proof systems are not permissionless, and only a few validators submit fraud proofs.
-
Solution 1:
Permissionless fraud proofs provided by Arbitrum’s BOLD protocol. The primary reason fraud proofs are currently permissioned is to guard against latency attacks:
- During the challenge period, any staker besides the proposer can initiate a challenge. Then, the proposer must defend against each challenger individually. At the end of each round, the losing party’s stake is slashed.
- In latency attacks, malicious actors (or groups) can delay or prevent results from being confirmed on the Layer 1 chain by initiating challenges and deliberately losing disputes and stakes.
- To solve this, the BOLD challenge protocol ensures a single honest entity in the world can defeat any number of malicious claims, guaranteeing Optimistic Rollup settlement confirmation time does not exceed a certain upper bound.
Witness Chain can act as a monitor for new Optimistic Rollups to ensure at least one honest party challenges invalid states:
- Mature Rollups like Arbitrum and Optimism have sufficient intrinsic incentives encouraging third-party providers (e.g., browsers, Infura-like services, and their foundations) to monitor chain states and submit fraud proofs when necessary. However, newer Rollups or app chains may lack this level of security.
- Witness Chain introduces a unique incentive mechanism called “Proof of Diligence,” ensuring monitors (validators) always have incentives to monitor and verify transactions, guaranteeing states submitted to the main chain are correct. This mechanism ensures every validator diligently performs their duty, as rewards are specific and independent per node. In other words, if a validator discovers a bounty, it cannot share the reward with others, ensuring independent validation by each node. Moreover, Witness Chain allows Rollups to specify custom requirements (such as the number of validators and their geographic distribution, supported by independent “proof-of-location” services), offering greater flexibility and balancing security and efficiency.
* Watchtower networks are emerging as a new layer in the Rollup stack, providing comprehensive security for other related applications (like Rollup security itself, interoperability protocols, notification services, and keeper networks). More details will be released later.
-
Trust Assumption 2:
The entire settlement process of smart contract Rollups is written in Layer 1 smart contracts. Assuming the logic of the smart contract on the DA layer is accurate, bug-free, and free from malicious upgrades.
-
Security Issue 2:
Smart contract Rollup bridges and upgrades are controlled by multisig wallets. Bridges could maliciously upgrade and arbitrarily steal user funds.
-
Solution 2:
Currently, the most common approach is adding a time delay, allowing users to exit if they disagree with planned upgrades. However, this requires users to constantly monitor all chains where their tokens reside in case they need to exit.
Altlayer’s Beacon Layer can serve as a social layer for all Rollups, providing upgrade services. Regardless of whether the bridge contract on Ethereum upgrades, sequencers running Rollups alongside Beacon Layer validators can socially fork the Rollup.
In the long term: Enshrined Rollup has long been Ethereum’s roadmap end goal. Besides enshrining bridges/fraud proof verifiers on Layer 1, settlement contracts are also enshrined.
- Ethereum PSE is moving in this direction.
For sovereign Rollups, the main difference is that chain state is settled by Rollup full nodes rather than smart contracts on Layer 1. For a more detailed comparison, see https://www.cryptofrens.info/p/settlement-layers-ethereum-rollups
Note that increased security does not imply improved performance. Generally, enhanced security measures require trade-offs in scalability. Therefore, balancing these two aspects is crucial. In short, Rollups offer flexibility, allowing users to choose different levels of security assumptions based on personal preferences. This adaptability is a defining characteristic of the modular world, enabling tailored solutions for specific needs while maintaining system integrity.
Balancing Customizability and Interoperability
In the modular world, there's a well-known maxim: “Modularism, not maximalism.” If Rollups cannot interoperate securely and efficiently, modularism becomes fragmentation rather than maximization. Hence, interoperability between different Rollups must be addressed.
First, let's recall how monolithic chains achieve interoperability. In short, cross-chain operations are realized by verifying consensus or state from other chains. Currently, various approaches exist, differing in who is responsible for verification (official entities, multisig mechanisms, decentralized networks, etc.) and how verification correctness is ensured (through external parties, economic guarantees, optimistic mechanisms, zero-knowledge proofs, etc.). For deeper insights, check out my favorite bridge article: Thoughts on Interoperability.
With the rise of modularity, interoperability issues become more complex:
Fragmentation Problem:
-
Will the surge in Rollups significantly exceed the number of Layer 1s, given that deploying on Layer 2 is much easier than on Layer 1? Will this lead to severe network fragmentation?
-
While monolithic blockchains provide consistent consensus and state for simple verification, what would verification look like if modular blockchains consist of three (or possibly four) distinct components (data availability, execution, settlement, and sequencing)?
Data availability and settlement layers become the primary data sources. Since Rollups themselves provide execution proofs, execution verification is already available. Sequencing occurs before publishing to the DA layer.
Scalability Problem:
-
With new Rollups emerging, a question arises: Can bridging services accommodate new Rollups in a timely manner? Even if Rollup deployment is permissionless, you might still spend 10 weeks convincing others to add a Rollup. Current bridging services mainly focus on mainstream Rollups and tokens. With potentially many new Rollups flooding in, concerns arise about whether these services can effectively evaluate and roll out solutions supporting them without compromising security and functionality.
User Experience Problem:
-
Optimistic Rollup final settlement takes seven days, much longer than other Layer 1s. The current challenge is resolving the seven-day waiting period for official Optimistic Rollup bridges. There's also time latency in submitting zero-knowledge proofs, as Rollups typically wait to accumulate large batches of transactions before submitting proofs to save verification costs. Popular Rollups like StarkEx often publish proofs to Layer 1 only every few hours.
-
To save costs, Rollup transaction data submitted to the DA/settlement layer experiences time delays (as mentioned above, 1–3 minutes for Optimistic Rollups, several hours for zk Rollups). This needs abstraction for users needing faster, more secure finality.
The good news is that new solutions have emerged to tackle these challenges:
Fragmentation Problem:
-
Despite the proliferation of Rollups in the ecosystem, it’s noteworthy that most current smart contract Rollups share a common settlement layer—Ethereum. Their main differences lie in the execution and sequencing layers. For interoperability, these Rollups only need to mutually verify the final state of the shared settlement layer. However, sovereign Rollups present a slightly more complex situation. Due to differing settlement layers, achieving interoperability among sovereign Rollups poses challenges. One way to solve this is establishing peer-to-peer (P2P) settlement mechanisms, embedding lightweight clients of each chain directly into others to facilitate mutual verification. Another approach is having these sovereign Rollups first bridge to a centralized settlement hub, acting as intermediaries connecting other chains. This hub-centric approach simplifies processes and ensures tighter interconnectivity among different Rollups. (Similar to Cosmos' state of interoperability)
-
Besides Ethereum, other potential settlement hubs include Arbitrum, zkSync, and StarkNet, serving as settlement centers for Layer 3s built atop them. Polygon 2.0’s interoperability layer also acts as a central hub for zk Rollups built on it.
-
In summary, despite growing numbers and variants of Rollups, the number of settlement centers remains limited. This effectively simplifies topology, narrowing fragmentation down to a few key centers. While the number of Rollups will exceed alternative Layer 1s, interactions between Rollups are simpler than between Layer 1s, as Rollups usually operate within the same trust/security scope.
-
Interoperability between different settlement centers can reference existing methods for interoperability between monolithic chains mentioned earlier.
* Additionally, to eliminate fragmentation on the user side, certain Layer 2s including ZKSync have integrated native account abstraction for seamless cross-Rollup experiences.
Scalability Problem
-
Hyperlane (providing modular security for modular chains) and Catalyst (permissionless cross-chain liquidity) have emerged to solve permissioned interoperability issues.
Hyperlane essentially creates a standardized security layer applicable to various chains, making them natively interoperable.
Catalyst aims to provide permissionless liquidity for modular chains. Catalyst acts as a bridge, allowing all new chains to seamlessly connect and exchange liquidity with major hubs like Ethereum and Cosmos.
-
Rollup SDK/RAAS providers offer native bridging services within their ecosystems
Currently, most new Rollups launch via existing Rollup SDKs or RAAS services, making them inherently interoperable with other Rollups using the same service. For example, infrastructure built on OP Stack has a base layer as a shared bridging standard, enabling assets to move seamlessly between all content sharing the OP Stack codebase. Rollups launched via Altlayer are encapsulated into the Beacon Layer, which acts as a settlement center and ensures secure interoperability. Rollups launched via Sovereign Labs or zkSync rely on proof aggregation for direct interoperability (to be explained in detail later).
User Experience Problem:
-
Before diving deeper, let’s first understand different commitment levels and their associated time delays:
Some participants are satisfied with Layer 2’s first-stage pre-commitment—for example, exchanges like Binance consider transactions confirmed after waiting for a certain number of Layer 2 blocks, without waiting for batch submission to Layer 1.
Bridge providers like Hop Protocol obtain as many blocks as possible on the sending chain and determine finality based on Layer 1 consensus (second stage).
For users seeking trust-minimized bridging or withdrawing funds from Layer 2 to Layer 1 using official bridges, this duration might be too long (ranging from hours to seven days).
-
The benefits of shortening the second or third stage are obvious: providing users with a safer, faster experience and stronger guarantees in less time. Additionally, achieving trust-minimized bridging has long been a desirable goal, especially considering frequent bridge security incidents.
-
Shorten final settlement time (seven days for Optimistic Rollups, several hours for zk Rollups), i.e., shorten Stage Three
Hybrid Rollup (Fraud Proof + Zero-Knowledge): This approach combines advantages of zero-knowledge proofs and Optimistic Rollups. Although generating and verifying proofs can be resource-intensive, they are executed only when state transitions are challenged. Unlike publishing zero-knowledge proofs for every batch, proofs are computed and published only when proposed states are challenged, similar to Optimistic Rollups. This shortens the challenge period, as fraud proofs can be generated in one step, saving zero-knowledge proof costs in most cases.
- Notably, Eclipse’s SVM Rollups and LayerN leverage RISC 0 to generate zero-knowledge fraud proofs. OP Stack already supports Risc 0 and Mina for developing zero-knowledge fraud proofs. Additionally, Fuel recently launched a similar hybrid approach supporting multiple provers.
After publishing data to the DA layer, perform additional verification on execution correctness to increase confidence—this is high-assurance, equivalent to full nodes.
- When the sequencer sends transaction batches to an Optimistic Rollup’s DA layer, it ensures canonical ordering and data availability for cross-Rollup transactions. Thus, the only thing left to confirm is execution: S1 == STF(S0, B1). Of course, you could run a full node (high-assurance) to verify transactions, but what we really want is reduced latency for light clients. Prover networks like SuccinctLabs and RiscZero can provide succinct state proofs to confirm post-execution states, giving dApps and users reliable confirmation.
- Altlayer has a Beacon Layer between Rollup and Layer 1. The Beacon Layer’s sequencer handles sequencing, execution, and generates Proof of Validity (POV). Validity proofs allow validators to later verify Rollup state transitions without accessing the entire state. Through regular checks by decentralized validators, we achieve highly robust transaction finality. There’s no need to wait seven days, as validators have already performed necessary checks, enabling faster and more secure cross-chain messaging.
- EigenSettle ensures verification through economic mechanisms. Participating EigenLayer nodes compute to ensure state validity and back their commitments with stakes. As long as amounts are below the stakes posted by these operators, settlements are deemed secure, enabling economically-backed interoperability.
Instant Verification Using ZK Rollup:
- Sovereign Labs and Polygon 2.0 adopt an innovative approach, bypassing the settlement layer for fast finality. We can immediately propagate generated zero-knowledge proofs via peer-to-peer networks and execute cross-chain operations based on propagated proofs, without waiting to submit proofs to Ethereum. Later, we can recursively combine them into batch proofs and submit them to Layer 1 when economically viable.
-- Nevertheless, we still need to trust the correct aggregation of zero-knowledge proofs. Polygon 2.0’s aggregators can operate in a decentralized manner, involving Polygon validators from a shared validator pool, improving network validity and censorship resistance. Since aggregating zero-knowledge proofs from multiple chains is clearly faster than waiting for sufficient proofs on a single chain, this method also shortens finality time.
- Zksync’s Hyperchain uses a hierarchical approach to aggregate zero-knowledge proofs, achieving shorter finality times. Unlike settling on Layer 1, Hyperchain settles its proofs on Layer 2 (becoming Layer 3). This helps accelerate message delivery, as the economically efficient environment on Layer 2 enables rapid and cost-effective verification.
-- To further enhance scalability, we can replace Layer 2 settlement with minimal programs required for running Layer 3 and message passing. This concept has been proven through specialized proofs capable of aggregation.
-
Solving time delays in publishing data to the DA layer (some methods can also shorten settlement cycles), i.e., shorten Stage Two
Shared sequencing layer: If Rollups share a sequencing layer (e.g., through a shared sequencer service or using the same set of sequencing layers), Rollups can receive soft confirmations from the sequencer. Combined with economic mechanisms, this scheme can ensure final state integrity. Possible combinations include:
- Stateless shared sequencer proposed by Espresso + builders making execution commitments via staking. This approach suits Rollups with PBS architecture, assuming block builders already have necessary permissions for partial blocks. Since builders are stateful and serve as foundational execution roles for the shared sequencer, they naturally make additional commitments.
- Shared validity sequencing proposed by Umbra Research: stateful shared sequencer + fraud proofs jointly ensure good behavior. The sequencer accepts cross-chain requests. To prevent dishonest sequencer behavior, a shared fraud proof mechanism is used, slightly modified from original Rollup fraud proof
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@SevenXVentures
