As we stand on the cusp of significant change, embracing the principles of security, interoperability and cost-effectiveness is critical.
Original author: Grace Deng, researcher at SevenX Ventures
Original source: mirror
Original title: Infrastructural Frontiers for Multi- Rollup World
Compiled by: Yvonne, Mars Finance
Recently, there has been a clear trend with more and more dApps announcing the launch of their own Rollup applications. In addition, the number of upcoming universal rollups is also increasing.
As Ethereum faces issues with rising transaction volume and dApp growth, Universal Rollup solves Ethereum’s scalability issues. These layer 2 solutions can handle more transactions off-chain and then ensure security on the main chain, thus striking a balance between scalability and security. Their versatility supports a variety of dApps, eliminating the need for unique scaling solutions for each application.
Application-specific Rollups are solutions tailored to meet the unique needs of individual applications. They increase speed by optimizing transaction processing for specific use cases. In terms of cost, they may be more effective than universal solutions, especially when the network is congested. Their outstanding feature is flexibility. Unlike general-purpose Layer 2 solutions that are more rigid and more limited by the EVM design, application-specific Rollups can be customized, making them ideal for applications that require specific precompilation, such as games. Additionally, they allow dApps to better capture value, providing more control over token economics and revenue streams.
As consensus builds around the popularity of Rollups, and looking ahead to the year ahead, multiple Rollups will dominate the market and the need for robust infrastructure becomes critical. This infrastructure will act as the "reinforced concrete" of the multi-Rollup world.
This article will delve into the four fundamental pillars that will shape the multi-rollup ecosystem of the future:
Security is the foundation: The security layer is the cornerstone of trust in the decentralized world. In this section, we explore the important role it plays in ensuring the integrity of Layer 2 transactions, determining trust assumptions, and addressing potential security risks.
Balancing customizability and interoperability: Achieving seamless interoperability between different modules is key in a modular blockchain world. In this section, we take a deep dive into the interoperability issues that come with modular structures and discuss current solutions to address fragmentation and build a cohesive ecosystem.
Cost Analysis: Reducing costs lowers economic barriers compared to using smart contracts and is therefore critical to wider adoption of Rollup technology and increasing its feasibility. To realize the cost-effectiveness of Rollup transactions, it is mainly to share fees by aggregating with other Rollup transactions, thereby taking advantage of economies of scale, and to achieve division of labor by delegating certain tasks to external service providers.
Shared Security: Shared security layers are critical as it eases the time- and resource-intensive process of launching security for a new protocol or module layer, ensuring strong security comparable to established platforms like Ethereum.
Together, these four layers will provide a comprehensive blueprint for the infrastructure needed to support a prosperous, cohesive, modular blockchain world.
Safety is the foundation
At the core of any decentralized system are trust and security. A lack of trust and security undermines the promise of a trustless ecosystem. This is why a security layer is critical; without it, both users and TVL are at risk. The decline of Plasma and Sidechains provides a cautionary tale. Ethereum was once seen as the savior of scaling, but its issues, such as “data availability issues,” eroded trust in it and led to a decline in its popularity. This is why security layers are the first part of this article.
To understand the complexity of Rollup and its potential vulnerabilities, it is necessary to dissect the life cycle of second-layer transactions. Using smart contract Rollup as a reference, let’s dive into each stage to identify trust assumptions and potential security risks:
Send transaction via RPC:
Trust assumptions: RPC endpoints are reliable and secure. Users and applications now trust RPC providers such as alchemy, infura, etc.
Security Concerns: Users may be censored by RPC providers such as infura and alchemy that block RPC requests to tornardo cash. RPC providers may be exposed to DDOS attacks, for example, ankr was attacked via DNS hijacking.
Solution: RPC providers such as Infura are actively pursuing decentralization roadmaps. In addition, users can also choose decentralized solutions such as Pocket Network.
Sequencer command sent, providing soft promise: unsafe state
Trust assumption: Users expect the sequencer to sequence transactions fairly and provide true soft commitments.
Security Issues: The system must be resistant to censorship, ensuring that all transactions are processed without bias. It is critical that the system remains operational, preferably to prevent the sequencer from acquiring bad MEVs to the detriment of end users.
solution:
The current solution sorts according to CR and validity level (low to high): single sorter – POA – no permission POS sorter – shared sorter – based on rollups (sorted by L1).
It should be noted that a POA with limited permissions that does not support forced txn may have a lower CR value compared to a centralized orderer with forced txn enabled.
Regarding effectiveness, another key metric to consider is proposer failures, which are failures that occur when the proposer is offline. In this case, it must be ensured that users can still withdraw funds.
Even if the sequencer is censoring or rejecting the work, some upgrade systems allow users to submit transactions directly to L1 themselves, i.e. an escape hatch (the effectiveness of forced transactions depends on the specific implementation). The problem is that the cost of doing this may be too high for users with limited funds, and users may expect real-time CR and real-time performance.
Some Rollup solutions, such as Arbitrum and Fuel, allow anyone to become a proposer after a certain delay, i.e. self-propose.
Please view the indicators for each Rollup scenario: https://l2beat.com/scaling/risk
For more details on different other solutions, see my previous thread: https://twitter.com/yuxiao_deng/status/1666086091336880128
MEV protection:
Different privacy solutions can help protect users from being preempted or flanked after their sent information is hidden (also helps with CR). Related methods for hiding transaction information include FCFS with private mempool (currently being implemented by arbitrary and optimization), SUAVE's TEE solution, threshold encryption (under study by Shutter Network), etc. The more complex the solution, the less complex calculations are required for the transaction.
MEV Roast | Encrypted Mempools – Justin Drake (Ethereum Foundation) – YouTube
Note that we want MEV protection, not MEV elimination. @tarunchitra's research summarizes two main directions for reducing MEV: reducing miners' flexibility to reorder transactions by enforcing ordering rules, and introducing a competitive market for the right to reorder, add/review transactions. However, this article concludes that neither fairness ordering nor economic mechanisms alone can effectively mitigate the MEV of all payment functions. In some cases, there is a lower limit to the inability to eliminate MEV.
When economically justified, the sequencer executes and publishes the transaction batch and state root to the DA layer; secure state
Trust assumption: The block producer publishes the entire block at the DA layer for others to download and verify.
Security issue: If some data is unavailable, blocks may contain malicious transactions hidden by the block producer. Even if a block contains non-malicious transactions, hiding these transactions can compromise system security. It is important that the sequencer has transaction data available, as Rollup needs to know the network status and account balances.
solution:
Publishing data on Ethereum is the safest but also most expensive solution right now (protodankshadring will be 90% cheaper later, but even with a 10x increase in throughput it may still not be enough for Rollup): all Ethereum nodes will download and Spread the Rollup deal. Since Ethereum has a large number of nodes replicating and validating transaction data, there is a small chance that the data will disappear or become completely unavailable.
After danksharding, Ethereum nodes will not download all transaction data, but only use DAS and KZG to download part of the data (similar to the avail solution mentioned below).
Under the modular concept, it may be more efficient to publish transaction data to the DA layer, which is only responsible for DA (the theoretical performance of Ethereum may be slightly inferior, because in addition to DA, it also retains the execution of L1, see eigenDA below Performance comparison with Ethereum).
Current modular DA solutions require a trade-off between security and performance. It is challenging to compare the security of DA from only one dimension:
Avail and Celestia use DAS to ensure data availability; as long as there is sufficient sampling, the data is safe. LCs can sample and achieve higher DA guarantees because data unavailability is easily detected and recovered by a very small number of LCs. This would not be possible without DAS. The decentralization of the DA layer, i.e. the number of nodes in the network, determines the security level and distribution of benefits. EigenDA does not use DAS, but uses an escrow proof mechanism to prevent restorers from being lazy, i.e. the DA operator must routinely calculate a function that can only be completed after downloading all the required data, and if the blob cannot be properly proven, it will be slashed (However, there is no need to store it after the proof is completed).
Ensure the accuracy of the data copying process (i.e. erasure coding). EigenDA, Ethereum after 4844, and Avail use kzg commitments to guarantee accuracy, but these are computationally intensive. Celestia uses fraud prevention technology. Light nodes must wait for a short interval to confirm that a block has been correctly encoded and finalize the block from their perspective. (Celestia may switch to validity proofs if they are a better trade-off option.)
Economic security of the DA layer (reorganization and collusion risk): depends on the pledge value of the DA layer, = 2/3 of the pledge value in Avail and Celestia
Forward the DA proof of the DA layer to Ethereum. If the data is published to another DA layer while the settlement contract is still in Ethereum, then we need a bridge contract to verify whether the DA in the DA layer is available for final settlement.
Celestia's blobstream verifies the signature on the DA certificate from Celestia. The proof is a Merkle root of L2 data signed by a Celestia validator, proving that the data is available on Celestia. The feature is currently available on testnet.
Avail adopts an optimistic approach to verify DA proofs. Once a proof is posted to the bridge contract on Ethereum, a waiting period begins, during which the proof is considered valid unless challenged.
Succinct is working with Avail and Celestia to develop a data authentication bridge based on zk-SNARK, which only needs to verify the zk certificate, making the authentication process more secure and cheaper.
For EigenDA, the decentralizer splits and publishes tasks to EigenDA nodes, then aggregates the signatures within them and forwards the data to Ethereum.
final settlement: final state
Trust assumption 1:
Rollup full nodes (nodes that can fully compute state without relying on other proofs) can complete final settlement at their height as soon as the first valid Rollup block is published on the parent chain because they have the necessary data and computing resources , which can quickly verify the validity of the block. However, this is not the case for other third parties, such as light clients, which rely on validity proofs, fraud proofs, or dispute resolution protocols to verify state without running a full copy of the chain themselves.
Security question 1:
For ZK Rollup, L1 verifies zkp and only accepts correct state roots. The difficulty lies mainly in the cost and generation process of zkp.
Optimistic Rollup, on the other hand, is premised on the fact that at least one honest party will promptly submit proof of fraud to challenge any malicious transactions. However, most current fraud proof systems are not yet permissionless, and the submission of fraud proofs relies on only a small number of validators.
Solution 1:
Permissionless fraud proof is achieved through Arbitrum's BOLD protocol. Currently, fraud proofs are allowed, primarily due to concerns about latency attacks:
During the challenge period, any challenger other than the proposer may initiate a challenge. The proposer then needs to defend each challenger one by one. After each challenge ends, the losing party will forfeit their stake.
In a delay attack, a malicious party (or malicious group) can prevent or delay the result from being confirmed back to the L1 chain by raising a challenge and deliberately losing the dispute and staking. )
To solve this problem, the BOLD challenge protocol guarantees a fixed upper limit on the OptimisticRollup settlement confirmation time, ensuring that a single honest party can defeat any number of malicious claims.
The Witness Chain can act as a "watchtower" for the new OptimisticRollup to ensure that at least one honest party will challenge the invalid state:
For mature Rollup chains such as Arbitrum and Optimism, there is sufficient intrinsic motivation for third-party providers such as Explorers, Infura-like services, and their foundations to monitor the status of the chain and submit fraud proofs when necessary. However, new encryption or application chains may lack this level of security.
Witness Chain adopts a unique incentive mechanism - "Proof of Diligence", which ensures that the supervision tower (verifier) always has the motivation to supervise and verify transactions, ensuring that the status submitted to the parent chain is correct. This mechanism ensures that each monitoring tower performs its duties because the rewards they receive are specific and independent for each node. In other words, if a watchtower discovers a bounty, it cannot share the exact reward payout with other watchtowers, ensuring that each node is independently verified. Additionally, Witness Chain provides flexibility by allowing Rollup to specify custom requirements such as the number of watchtowers and their geographical distribution driven by Proof of Location (its independent service). This flexibility ensures a balance between safety and efficiency.
*Watchtower Network will also appear as a new layer within the Rollup stack itself, providing pooled security for execution used by other related applications such as Rollup Security itself, interop protocols, notification services, and the Guardian Network, among others. More details will be released in the future.
Trust assumption 2:
The entire process of smart contract Rollup settlement is written using smart contracts on L1. It is assumed that the smart contract logic on the DA layer is accurate, has no loopholes, and has not been maliciously upgraded.
Solution 2:
The most popular idea right now is to add a time delay that would allow users to back out if they don't agree to a planned upgrade. However, this solution requires users to continuously monitor all chains where they own tokens in case they need to exit.
Altlayer's Beacon Layer can act as a social layer and provide upgrade services for all Rollup chains on it. Orderers that register to operate Rollup in conjunction with the beacon layer Rollup validator can socially fork Rollup regardless of whether the bridge contract on Ethereum is upgraded.
Enshrined rollup: Enshrined rollup has been the ultimate goal of the Ethereum roadmap for several years.
As for sovereign Rollup, the main difference is that the chain state is settled by Rollup full nodes instead of smart contracts in L1. For a more detailed comparison, please refer to https://www.cryptofrens.info/p/settlement-layers-ethereum-rollups
It's important to note that greater security does not equate to better performance. Often, as security measures are added, there is a trade-off for scalability. Therefore, a balance must be struck between the two. In summary, Rollup provides the flexibility to choose different levels of security assumptions based on personal preference. This adaptability is one of the distinguishing features of the modular world, allowing for a tailor-made approach to meet specific needs while maintaining the integrity of the system.
Balance customizability and interoperability
There’s a well-known adage in the modular world: modularize, not maximize. If components cannot interoperate safely and efficiently, then modularity ≠ maximizes, but equals fragmentation. It is crucial to understand how to handle interoperability between different Rollups.
Let’s first review how single chains achieve interoperability. At its simplest, they enable cross-chain operations by validating the consensus or state of other chains. There are multiple approaches on the market, differing in who is responsible for verification (official entities, multi-signature mechanisms, decentralized networks, etc.) and how the correctness of the verification is ensured (through external parties, economic guarantees, optimistic mechanisms, zk-proofs, etc. ). For a deeper dive into this topic, check out my favorite bridging article: Thoughts on Interoperability .
With the rise of modularity, interoperability issues have become more complex:
Fragmentation problem:
Since logging into L2 is much easier than logging into L1, the number of Rollups is expected to greatly exceed the number of L1s. Will this lead to a highly decentralized network?
Monolithic blockchains provide consistent consensus and state that can be directly verified, whereas modular blockchains have three (or possibly four) different components (DA, execution, settlement, and ordering) whose verification process would be What kind of thing?
The DA and settlement layer become the primary source of truth. Execution verification already exists because Rollup itself provides proof of execution. Sorting occurs before publishing to DA.
Scalability issues:
When new rollups are introduced, the question arises: can we provide bridging services in time to accommodate them? Even if setting up a Rollup project is permissionless, you may need to spend 10 weeks convincing others to add a Rollup project. The current bridging service mainly targets mainstream Rollup projects and tokens. With the potential influx of large amounts of cryptocurrencies, there are concerns about whether these services can efficiently evaluate and roll out solutions to support these emerging cryptocurrencies without compromising security and functionality.
User experience issues:
Final settlement of Optimistic Rollup takes seven days, which is much longer than other L1s. Addressing the seven-day wait time for Optimistic Rollup to officially bridge was a challenge. There is also a time difference in submitting zkp, because Rollup usually waits until a large number of transactions have been accumulated before submitting the proof to save verification costs. Popular rollups like StarkEx typically release proofs to L1 only every few hours.
To save costs, there will be a time difference in transaction data submitted to the DA/settlement layer (as mentioned above, 1-3 minutes for Optimistic Rollup and hours for zk Rollup). This is useful for users who require faster and more secure end results. It needs to be abstracted.
The good news is that there are new solutions to these challenges:
Fragmentation problem:
Although there are endless rollup layers in the ecosystem, it is worth noting that most smart contract rollup layers currently have a common settlement layer, which is Ethereum. The main difference between these Rollups is their execution and ordering layers. To achieve interoperability, they only need to mutually verify the final state of the shared settlement layer. However, for sovereign cryptocurrencies, the situation becomes slightly more complicated. Their interoperability is challenging due to different settlement layers. One way to solve this problem is to establish a peer-to-peer (P2P) settlement mechanism, where each chain directly embeds the other's light client, thereby promoting mutual verification. Alternatively, these sovereign rollups could first be connected to a central settlement center, which would then serve as a conduit to other chains. This hub-centric approach simplifies the process and ensures a more cohesive interconnection between different Rollup chains.
In addition to Ethereum as one of the settlement centers, other potential settlement centers include Arbitrum, zkSync, and StarkNet, which are settlement centers for L3 built on top of it. Polygon 2.0's interop layer is also the central hub for zk rollups built on top of it.
In summary, while the number of rollups and their variations is constantly expanding, the number of settlement centers is still limited. This effectively simplifies the topology, reducing the fragmentation problem to a few key hubs. Although there are more rollups than alt L1s, interactions across rollups are less complex than interactions across alt L1s because rollups generally belong to the same trust/security scaling scope.
How to interoperate between different settlement centers can refer to the interoperability between current single chains mentioned at the beginning.
Additionally, to eliminate fragmentation on the user side, some layer 2s such as ZKSync have integrated native account abstractions to facilitate a seamless cross-rollup experience.
scalability issues
Hyperlane (providing modular security for modular chains) and Catalyst (permissionless cross-chain liquidity) were born to solve the problem of permissioned interoperability.
The essence of Hyperlane is to create a standardized security layer that can be applied to various chains, making them inherently interoperable.
Catalyst aims to provide permissionless liquidity to module chains. It acts like a bridge, allowing any new chain to seamlessly connect liquidity and exchange with major hubs like Ethereum and Cosmos.
Rollup SDK/RAAS providers provide native bridging services in their ecosystem.
Now, new Rollups are mostly launched through existing Rollup SDK or RAAS services, so they are inherently interoperable with other Rollups using the same service. For example, for infrastructure built using OP Stack, the base layer is the shared bridging standard, which allows assets to be moved seamlessly between all devices sharing the OP Stack code base. For Rollup projects launched through Altlayer, they are incorporated into the beacon layer as a settlement center to ensure secure interoperability. For Rollup projects launched through sovereign labs or zksync, they are interoperable out of the box based on proven aggregation (more on this later).
UE question:
Before we dive into this, let’s first understand the different levels of commitment and their time lags:
Some parties are comfortable with L2's soft Phase 1 commitment, with exchanges such as Binance only having to wait for a certain number of Layer 2 blocks to consider a transaction confirmed, rather than waiting for a batch to be submitted to Layer 1.
Some bridging providers (like hop protocol) will fetch as many blocks as possible on the sending chain and determine finality based on layer 1 consensus (phase 2).
For trust-minimized bridges and users using official bridges to withdraw funds from L2-L1, it may take too long (several hours and 7 days).
Reducing Stage 2 or Stage 3 will bring significant advantages, providing stronger guarantees in a shorter period of time, resulting in a safer and faster user experience. In addition, achieving trust-minimized bridges has always been a coveted goal, especially when bridge security incidents occur frequently.
Shorten the final settlement time (7 days for Optimistic Rollup and several hours for zk Rollup), that is, shorten the time of Phase 3.
Hybrid Rollup (Fraud Proof + ZK): This method combines the advantages of ZK Proof and Optimistic Rollup. While generating and verifying proofs is resource intensive, they are only performed when a state transition is challenged. Similar to Optimistic Rollup, this approach does not require issuing ZK proofs for every batch of transactions, but instead only computes and issues proofs when the proposed state is challenged. This shortens challenge time because fraud proofs can be generated in just one step and avoids the cost of ZK proofs in most cases.
It is worth noting that Eclipse's SVM rollups and LayerN use risc0 to generate zk fraud proofs. OP Stack supports Risc0 and Mina to develop zk fraud proofs. Additionally, Fuel recently introduced a similar hybrid approach that supports multiple provers.
After publishing the data to the DA layer, do some additional verification of the correctness of the execution to increase confidence - very demanding, same as full nodes.
When the sequencer sends a batch of transactions to the DA layer of Optimistic Rollup, it ensures canonical ordering and DA of x-Rollup transactions. Therefore, the only confirmation required is to execute: s1 == stf(s0, b1). Of course, you can also run a full node (high demand) to validate transactions, but what we really want is to reduce the latency of light clients. Prover networks like @SuccinctLabs and @RiscZero can confirm post-execution state by providing concise state proofs. This provides powerful confirmation capabilities for dapps and users.
Altlayer has a beacon layer between Rollup and L1. The orderer of the beacon layer is responsible for ordering, execution and generating proof of validity (POV). POV allows a validator to later verify a Rollup's state transition without accessing the entire state. We achieve highly robust transaction finality by performing regular checks with decentralized validators. There is no need to wait 7 days as the validator has already completed the necessary checks. As a result, cross-chain messaging becomes faster and more secure.
EigenSettle guarantees verification through economic mechanisms. Opting-in EigenLayer nodes perform calculations to ensure the validity of the state and use their collateral to back their commitments. Any amount lower than the amount staked by these operators can be considered a secure settlement, enabling economically underpinned interoperability.
Instant verification using ZK Rollups:
Sovereign Labs and Polygon 2.0 have taken an innovative approach to achieve fast finalization by bypassing the settlement layer. We do not need to wait to submit the proof to Ethereum, but instantly propagate the generated zk proof through the peer-to-peer network and perform cross-chain operations based on the propagated zkps. We can then leverage recursion to combine them into batch proofs and submit them to layer 1 when economically feasible.
But this problem has not been completely solved, we still need to believe that zkp's aggregation is correct. Polygon 2.0's aggregator can operate in a decentralized manner, allowing Polygon validators from a shared validator pool to participate, thereby increasing network responsiveness and resistance to censorship. However, using this approach will also shorten the final processing time, since aggregating zkp on multiple chains is definitely faster than waiting for enough zkp on a single chain.
Zksync's hyperlinks use a hierarchical approach to aggregate zkp to achieve shorter finalization times. Instead of settling on L1, a hyperlink can settle its proof on L2 (becoming L3). This approach facilitates rapid information transfer because the cost-effective environment in L2 enables fast and cost-effective verification.
To further improve scalability, we can replace L2 settlement with the minimal program required to run L3 and message passing. This concept has been confirmed by specialized proofs allowing aggregation.
Solve the time lag problem of publishing to the DA layer (some methods can also be used to shorten the settlement period), that is, shorten stage2.
Shared ordering layer: If Rollups share an ordering layer (for example, by sharing a sequencer service or using the same set of ordering layers), they can get soft acknowledgments from the sequencer. This, combined with economic mechanisms, ensures the integrity of the final state. Possible combinations include:
The "stateless shared sequencer + generator" proposed by Espresso makes execution commitments through staking; this method is more suitable for Rollup with a PBS structure, provided that the block generator already has the necessary permissions for some blocks. Since the builder is stateful and acts as the underlying execution for the shared sequencer, it naturally makes additional commitments.
Umbra research proposes shared validity ordering: stateful shared orderer + fraud proof to ensure good behavior. The sequencer accepts cross-chain requests. In order to prevent dishonest behavior of the sorter, a shared anti-fraud mechanism is used, with slight changes to the original Rollup anti-fraud mechanism. During the challenge, challengers will also verify the correct execution of atomic operations. This might involve checking the root of the bridge contract on a different rollup, or checking the Merkle proof provided by the orderer. Dishonest sorters will be cut.
Third Party Intervention: External entities such as Hop, Connext and Across can step in to reduce risk. They verify information and fund users’ cross-chain financial activities, effectively reducing waiting times. For example, Boost (GMP Express) is a special feature of Axelar and Squid that can reduce the time of cross-chain transactions worth less than $20,000 to 5-30 seconds.
As a special form of third-party intervention, bridged intent infrastructure: This modified infrastructure can accommodate more third-party intervention and solve cross-domain intent issues for users.
With intent-centric architecture (which removes friction and complexity from users by involving complex actors such as MMs and builders), users can express their intended goals or outcomes without having to detail what is needed to achieve them precise transactions. Individuals with high risk tolerance can step in, provide the necessary funds, and charge higher fees.
It is more secure because user funds are only released when the results are valid. It may be faster and more flexible because more people (solvers) participate in the solving process without permission and compete to provide better results for users.
UniswapX, flashbots’ SUAVE and essential are all working in this direction. More information about intents:
nft://10/0x9351de088B597BA0dd2c1188f6054f1388e83578/?showBuying=true&showMeta=true
The difficulty with this solution is the settlement oracle. Let’s take UniswapX as an example. To facilitate cross-chain transactions, we rely on settlement oracles to decide when to release funds to solvers. If the settlement oracle chooses a native bridge (which is slow), or uses a third-party bridge (which raises trust issues), or even a light client bridge (which is not yet ready for use), we will find ourselves basically stuck with the same problem as before Same cycle. Therefore, UniswapX also provides a "fast cross-chain swap" function similar to the Optimistic bridge.
At the same time, the effectiveness of intent solving depends on competition between solvers. This can cause problems with centralized solvers since solvers need to rebalance inventories on different chains, limiting the full potential of the intent.
To sum up, it can be found that there are three methods to solve the UE problem:
Leverage the magic of zk:
The main challenge lies in the performance of ZK technology, including the time required to generate it and the associated costs. Furthermore, when dealing with highly customizable modular blockchains, the question arises: Do we have a proof-of-ZK system that can accommodate countless differences?
Use economic reduction programs to ensure:
The main disadvantage of this approach is the time delay inherent in decentralized methods (e.g. in the case of EigenSettle we have to wait for the upper limit to be reached). Additionally, centralized approaches offer limited commitments (take shared ordering as an example), rely on builders/orderers to make commitments, which can be limiting, and lack scalability.
Trust third parties
Trusting a third party may introduce additional risks, as users must have confidence in the bridge, whereas intent-enabled cross-domain exchanges represent a more "decentralized" form of third-party bridging. However, this approach still suffers from oracle latency, trust issues, and potential time delays since you have to wait for others to accept your intentions.
Interestingly, modularity also brings new possibilities for interoperability experiences:
Modular components increase speed: By breaking into finer modules, users can get confirmations from layer 2 faster (which may be safe enough for sequential users).
Atomic transaction shared sequencer: The concept of shared sequencer has the potential to enable new forms of atomic transactions, such as flash loans. For more details, please visit: https://twitter.com/sanjaypshah/status/1686759738996912128
Modular interoperability solutions are evolving rapidly, and there are currently multiple approaches, each with their own pros and cons. Perhaps the ultimate solution is still some way away from us, but it is gratifying that we see so many people working hard to create a safer and more interconnected modular world to avoid the Rollup explosion.
cost analysis
Compared with using smart contracts, the economic considerations of rolling out Rollup machines are one factor that leads to the limited number of Rollup machines. Operation through smart contracts adopts a model with high variable costs. The main expenditure is Gas fees, while starting and maintaining Rollup will incur fixed costs and variable costs. This cost dynamic suggests that applications with high transaction volumes or relatively high transaction fees are better suited to leverage Rollup, as they have a greater ability to amortize the fixed costs involved. Therefore, measures aimed at reducing rollup-related costs, both fixed and variable, are crucial. As Neel and Yao Qi explained at the ETHCC conference, delving deeper into the cost components of Rollup transactions can give us a clearer picture:
Using financial models such as discounted cash flow (DCF) analysis can help evaluate the feasibility of launching a rollup for an application. Calculated as follows:
DCF (Income - Expenditure) > Initial Investment
Serves as a baseline to determine whether operating income exceeds the initial investment, making rolling out an upgrade a financially sound decision. Solutions that successfully reduce operating costs while increasing revenue can help encourage greater adoption of Rollup solutions. Let’s explore each one:
Initial development and deployment costs
Despite the availability of open source SDKs such as Opstack and Rollkit, the initial setup still requires significant time and human capital to install and debug. Customization requirements, such as integrating virtual machines into SDKs, further increase the resources required to match virtual machines to the various interfaces provided by each SDK.
RAAS services such as AltLayer and Caldera can greatly reduce this complexity and workload, reflecting the economic benefits of division of labor.
Recurring expenses/income
Income (++++)
User fee = Level 1 data release fee + Level 2 operator fee + Level 2 congestion fee
While some user fees may be offset by expenses, it is critical to carefully review and work to reduce these costs because if user fees are too high, they may become unaffordable to users. (Discussed in the Fees section)
Miner Extractable Value (MEV) obtained
Mainly related to the transaction value from the chain, which can be improved by improving the extractable value (MEV) efficiency or increasing the cross-domain extractable value (MEV).
Cooperating with mature searchers, using PBS auctions to promote competition, or utilizing SUAVE's block construction services are all feasible strategies to optimize MEV acquisition efficiency.
To obtain more cross-chain MEV, it is beneficial to utilize shared ordering layers or SUAVE (shared mempool and shared block construction) as they can connect multiple domains.
According to Akaki’s latest research, shared orderers are extremely valuable to arbitrage hunters aiming to seize arbitrage opportunities on different chains, as they ensure victory in the race to be played on all chains simultaneously.
SUAVE serves as a multi-domain order flow aggregation layer to help builders/searchers explore cross-domain MEVs.
cost(- - -)
L2 operating fee
Ordering: Comparing centralized and decentralized ordering solutions can be tricky. Competing among more decentralized solutions such as “Proof of Efficiency” helps keep operators’ margins to a minimum, thus reducing costs, and also incentivizes batches to be released as frequently as possible. Centralized solutions, on the other hand, typically involve fewer parties and can streamline processes, but may not benefit from the same cost-reduction dynamics.
Execution: In this case, the full node uses a virtual machine/EVM to execute changes to the Rollup state by new user transactions.
Parallel execution can be achieved through optimized alternative virtual machines such as Fuel and Eclipse's Solana VM, thereby increasing efficiency. However, deviating from EVM compatibility can create friction for developers and end users, and introduce potential security issues. Arbitrum's Stylus is commendable for its compatibility with EVM and WASM (which is more efficient than EVM).
prove
prover market
In theory, leveraging dedicated validator markets such as Risc0, =nil, and marlin, rather than creating proprietary centralized or decentralized validator networks, could lead to cost savings for several reasons:
Participation in the dedicated validator market is likely to be higher, which in turn will promote competition and ultimately lead to lower prices.
Provers can optimize hardware usage and can be reused when a specific application does not require immediate proof generation, thereby reducing operating costs and providing a cheaper service.
Of course, there are drawbacks to this, including potentially capturing less utility of the token and relying on external parties for performance. Additionally, different zk rollups may impose different hardware requirements on the proof generation process. This variability can create challenges for provers looking to expand their attestation operations.
More information about prover markets and prover networks: https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
L1 data release
In addition to Ethereum, opting for a more cost-effective Data Availability (DA) layer, or even using a DAC solution, can significantly reduce expenses, but may come at the cost of reduced security (further explored in Security Layers). For gaming and social, which often have low value but high bandwidth, scalability may be a more important factor than security.
Using Ethereum as the DA layer can leverage native sharing and sharding to achieve cost efficiencies. Additionally, since the publishing fee for a blob is set per block, independent of how Rollup uses the blob, a balance needs to be struck between cost and latency: in an ideal world, Rollup would publish a complete blob, but if the transaction arrives If the rate is low, the blob space will be completely occupied, resulting in excessive delay costs.
Potential solution: joint blob publishing costs for small-scale rollups;
L1 Settlement Fee
For Optimistic Rollups, settlement fees are relatively low. After bedrock, Optimism only pays ~$5 per day to Ethereum;
For zk settlement, the cost of zkp verification is relatively high
zk proves aggregation
Depending on the underlying proof system, aggregation on Ethereum may cost 300,000 to 5 million Gas to verify a proof. But because the proof size grows very slowly (or not at all) with the number of transactions, Rollup can reduce the cost of each transaction by waiting to accumulate a large number of transactions before submitting the proof.
As mentioned before, the interoperability layer of Sovereign labs and polygon 2.0 aggregates the proofs of multiple Rollups. Each Rollup can verify the status of multiple Rollups at the same time, thus saving verification costs. Zksync's layered structure combined with proof aggregation further reduces verification costs.
However, this approach works best when both domains use the same ZKVM or shared prover scheme (zksync's hyperlink uses the same zkEVM and the exact same zkp circuit); otherwise, performance may suffer.
NEBRA Labs brings economies of scale and composability to proof verification on Ethereum. NEBRA UPA (Universal Proof Aggregator) can universally aggregate heterogeneous proofs to amortize verification costs. UPA can also be used to combine proofs from different sources to enable new use cases.
In summary, the main ways to save rollup costs include:
Join forces with other Rollup projects to share costs or take advantage of economies of scale:
Notably, this federation is also critical to achieving interoperability. As mentioned earlier, using a unified layer or framework in different Rollup projects can simplify the interaction between them and ensure barrier-free information exchange. This integration strategy promotes the integration and unification of second-tier infrastructure.
Use the principle of division of labor to delegate certain tasks to external service providers.
As more Rollup services emerge (meaning more parties you can work with to spread the cost), and as more Rollup service providers offer more granular services (providing more mature upstream provider choices), we expect The costs associated with setting up Rollup services will be reduced.
Share security
If your goal is to achieve the same level of security (in terms of economics and decentralization) as the source chain, just deploy a smart contract or smart contract rollup. If leveraging the partial security provided by the source chain is enough to improve performance, there are several shared security solutions currently available.
Shared security solutions greatly simplify the secure boot process for most protocol or module layers that require initial security. This makes a lot of sense for the future of the modular world, as we envision more foundations/protocols emerging to facilitate modular world functionality, and more parts of Rollup beyond DA, execution, settlement, and ordering. will become modular. If Rollup uses a certain module layer (such as DA) or a service whose security does not meet the requirements of Ethereum, the overall security of the entire module chain will be affected. We need shared security to enable a decentralized and reliable SAAS service economy.
Eigenlayer, Babylon and Cosmos' ICS and Osmosis' mesh security play a key role in providing decentralized trust services to other infrastructure entities.
Eigenlayer allows Ethereum holders to repurpose their ETH to secure other applications built on the network.
ICS for Cosmos allows the Cosmos Hub (the "providing chain") to lend its security to other blockchains (the "consuming chain") in exchange for fees.
Mesh Security is created through penetration and enables token delegators (rather than validators) to reclaim their tokens on partner chains within the ecosystem. This enables bidirectional or multilateral secure flows, as different application chains can combine their mcaps to enhance overall security.
Babylon allows BTC holders to stake their BTC within the BTC network and provides security to other POS chains by optimizing the use of Bitcoin scripting language and using advanced encryption mechanisms.
Both ICS and Mesh Security are part of the Cosmos ecosystem, and their main purpose is to promote secure borrowing between chains. These solutions primarily address the security needs of Cosmos application chains, enabling them to leverage the security of other chains in the ecosystem. Specifically, Cosmos Hub ICS provides a solution for Cosmos chains that do not want to bootstrap validator sets (replication security), while Mesh Security requires each chain to have its own validator set but allows for greater accountability in chain governance. Selectivity.
Babylon, on the other hand, proposes a unique approach to unlocking the potential of Bitcoin holders’ idle assets without moving Bitcoin off the native chain. By optimizing the use of Bitcoin scripting language and integrating advanced encryption mechanisms, Babylon provides additional security to the consensus mechanisms of other chains and has powerful features such as faster unbinding periods. Validators on other POS chains using BTC can lock their BTC on the Bitcoin network and sign POS blocks using the BTC private key. Invalid behavior such as double signing can leak a validator’s BTC private key and burn their BTC on the Bitcoin network. Babylon’s second test network will launch BTC staking.
Babylon thrives on Bitcoin's lack of smart contract support, while Eigenlayer operates on the Turing-complete Ethereum platform. Eigenlayer not only provides economic security for new rollups and chains, but its environment on Ethereum also allows More diverse AVS. According to eigenlayer's article on programmable trust, the security that eigenlayer can provide can actually be further broken down into 3 types:
Economic Trust: This trust model ensures consistency regardless of the number of parties involved. There must be objective price reduction conditions that can be submitted and verified on-chain, which often puts pressure on restorers.
Decentralized trust: The trust that comes with a decentralized network run by independent and geographically isolated operators. This aspect emphasizes the intrinsic value of decentralization and enables use cases that cannot be objectively proven because decentralization makes collusion more difficult. To take advantage of decentralized trust, lightweight trust is often required.
Ethereum embraces trust: Trust that Ethereum validators will build and include your blocks while running the consensus software as promised. This can be committed exclusively by Ethereum validators (not LST restorers). They run software sidecars to perform additional calculations and receive additional rewards.
Now that we know the safety material, what else can we expect?
ICS and mesh security lower the security barrier of Cosmos application chains such as neutron, stride, and axelar.
Eigenlayer can be adapted to many of the previously mentioned solutions:
Rollup security: relay network; watchtower, sorting, Mev-protection, EigenDA
Rollup interop: Eigensettle; bridge
Cost Analysis: prover network
To explore more, please visit https://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/
Babylon is running a test network to improve the security level of other POS chains. Its first test network provides timestamping services to add additional security to high-value DeFi activities from multiple Cosmos chains such as akash, osmosis, juno and more.
The core idea behind these shared security solutions is to increase the capital efficiency of pledged or illiquid assets by introducing additional liability. However, when seeking higher returns, one must be wary of increased risks:
Increased complexity creates more uncertainty. Validators will be faced with more cuts that may lack adequate training wheels, which may be in jeopardy.
Eigenlayer proposed the establishment of a veto committee aimed at resolving this issue. The committee is a trustworthy entity between bidders, operators and AVS developers. If a software bug occurs in AVS, stakers and operators will not be punished as the Veto Committee can cast a veto vote. While this approach may not be scalable by itself, and may be subjective if the AVS is not strictly tuned for use cases based on trustless attributable actions, it can still be important as a starting point for initiating a risk mitigation strategy at an early stage. means.
Higher complexity also brings additional burdens. For inexperienced validators, determining which service to share security with can be overwhelming. Additionally, there may be a higher risk of error during the initial setup phase. In addition, mechanisms should be established to allow “less tech-savvy” validators and bookkeepers to benefit from higher returns, provided they are willing to accept relatively high risks without being constrained by their operational capabilities .
Both Rio Network and Renzo are working to effectively address this challenge faced by Eigenlayer, by providing a structured approach to carefully select advanced node operators and AVS services for potential reshoots, increasing security levels and reducing participant access threshold.
Additionally, as Eigenlayer becomes more widely adopted, it has the potential to break new ground in the financialization of security. This will help in valuing shared security and the various applications built on it.
One limitation EigenLayer faces is that it cannot scale its system’s capital allocation by competing for yield opportunities in DeFi on the same assets it supports (LST). EigenLayer commoditizes the value of security, which opens the door for many fundamental elements to underwrite this value and provides restorers with the ability to re-underwrite and participate in the larger DeFi ecosystem.
Ion Protocol is a product that attempts to do just that, with the goal of expanding the reach of repricing. Ion is building a price-agnostic lending platform that specifically supports mortgaged and re-mortgaged assets by using ZK infrastructure to underwrite the lower levels of haircut risk present in such assets (ZK Proof of State System + ZKML) . EigenLayer commoditizes the fundamental value of security, which may be the beginning of many new DeFi primitive elements, further enhancing the ability to repricing throughout the ecosystem.
As we stand on the cusp of significant change, embracing the principles of security, interoperability and cost-effectiveness is critical. These pillars will not only guide the development of more scalable and efficient blockchain solutions, but will also pave the way for a more connected and accessible digital world. Meeting these changes with foresight and adaptability will undoubtedly bring groundbreaking progress to the blockchain ecosystem.
