This article is original by the SevenX research team and is for communication and learning purposes only and does not constitute any investment reference. If you need to cite, please indicate the source.
Original link: https://mirror.xyz/sevenxventures.eth/ iQ 7 i 5 BQLtDDqm 9 UROTyNLUMEtMkP 3 NbE 5 HoUSxORbLg
Author: Grace
Many thanks to @13 yearoldvc @prabalbanerjee @maqstik @ballsyalchemist @donnoh_eth @ChundaMcCain @shumochu @ranvirrana 001 and others for their contributions to the discussion and comments!
There has been a clear trend recently: more and more dApps have announced the launch of their own Rollup applications. In addition, the number of upcoming universal rollups is increasing day by day.
As the transaction volume and the number of dApps continue to grow, Ethereum is facing scaling problems, and universal Rollup came into being. These Layer 2 solutions process more transactions off-chain and then securely record those transactions on the main chain, perfectly balancing scalability and security. Rollup’s 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 an individual application, increasing speed by optimizing transaction processing for specific use cases. In terms of cost, this kind of rollup may provide a more efficient alternative, especially when the network is congested, this efficiency is particularly valuable. One of the great features of Rollup is its flexibility. General-purpose Layer 2 solutions are more rigid and more limited by the EVM design, while application-specific Rollups can be tailored, making them ideal for applications such as games that require specific precompilation. In addition, Rollup helps dApps capture value more efficiently and gain greater control over token economics and revenue streams.
As people gain consensus on the popularity of rollup technology, looking ahead to the next year, multiple rollups will dominate the market, so the first priority is to build a strong infrastructure to make it play the role of reinforced concrete.
This article will delve into the four basic pillars that will shape the future multi-Rollup ecosystem:
Security basics:Security layers are the cornerstone of trust in a decentralized world. In this section, we explore the critical role security layers play in ensuring the integrity of Layer 2 transactions, identifying trust assumptions, and addressing potential security risks.
Balancing customizability and interoperability:Achieving seamless interoperability between different Rollups is key to a modular blockchain world. In this section, we will delve into the interoperability issues brought about by modular structure and discuss how to solve the fragmentation problem and build a cohesive ecosystem.
cost analysis:The key to making Rollup widely available and feasible is to reduce costs, because lower costs lower economic barriers compared to smart contracts. The cost efficiency of Rollup is mainly achieved in two ways: one is to aggregate with other Rollups and share costs to achieve economies of scale, and the other is to delegate certain tasks to external service providers to achieve division of labor.
Sharing security:A shared security layer is essential because it reduces the time and resources required to secure a new protocol or module layer, giving it strong security comparable to established platforms such as Ethereum. There are many solutions out there, with apps like Eigenlayer, Babylon, ICS from Cosmos, and Mesh Security.
The above four levels create a comprehensive blueprint that drives the infrastructure required for a prosperous, cohesive, modular blockchain world.
Security Basics
Trust and security lie at the core of all decentralized systems. Without trust and security, the trustless ecosystem becomes water without a source. The security layer is crucial, without which both users and Total Value Locked (TVL) are exposed to risk. Plasma and Sidechains were once seen as the saviors of Ethereum scaling, but their decline is a wake-up call. Issues such as data availability undermine trust and ultimately cost users. For this reason, this article discusses the security layer as the first part.
To understand the complexity of rollups and their potential vulnerabilities, it is necessary to dissect the life cycle of a Layer 2 transaction. Taking smart contract Rollup as an example, we will delve into each stage and find out the trust assumptions and potential security risks:
Submit transaction via RPC:
Trust assumption: RPC endpoints are reliable and secure. Users and dApps now trust RPC providers like Alchemy, Infura, and others.
Security Issues: Users may be subject to censorship by RPC providers such as Infura and Alchemy blocking RPC requests to Tornardo Cash. RPC providers may be exposed to DDOS attacks, such as the DNS hijacking attack on ANKR.
Solution: RPC providers such as Infura are actively pursuing decentralization roadmaps. Additionally, users can opt for decentralized solutions like Pocket Network.
The sequencer sorts transactions, providing a pre-commitment: unsafe state
Trust assumption: Users believe that the sequencer can sequence transactions fairly and provide true pre-commitments.
Security issues: The system must be resistant to censorship, ensuring that all transactions are processed without bias. The system must be up and running at all times and ideally be able to prevent the sequencer from obtaining poor Maximum Extractable Value (MEV) at the expense of the end user.
solution:
Censorship Resistance (CR) and Liveness: Based on censorship resistance and effectiveness, current solutions are ranked (from low to high) as follows: Single Orderer - POA - Permissionless POS Ordering Sorter - shared sorter - based on Rollup (sorted by Layer 1).
It is important to note that a POA with limited permissions and no support for forced txn may be less censorship-resistant than a centralized orderer with forced txn enabled.
As for effectiveness, another key metric to consider is proposer failure, which occurs when a proposer is offline. In this case, it must be ensured that users can still withdraw funds.
- Even if the sequencer is reviewing or rejecting the work, some rollups allow users to submit transactions directly to Layer 1 themselves, i.e. emergency exits (the effectiveness of forced transactions depends on the specific implementation). The problem is that this may be cost-prohibitive for users with limited funds, and users may want censorship resistance and effectiveness at all times.
-Certain Rollup solutions, such as Arbitrum and Fuel, allow anyone to become a proposer, i.e. self-propose, after a certain time delay.
-View the metrics of each Rollup: https://l2b eat.com/scaling/risk
For more details on other different solutions, you can refer to my previous post: https://twitter.com/yuxiao_deng/status/1666086091336880128
MEV protection:
Different privacy solutions can help protect users from front-running or sandwich attacks because transaction information is hidden (also helping to improve censorship resistance). Methods to hide transaction information include: FCFS with private memory pools (a solution currently being implemented by Arbitrum and Optimism), SUAVEs TEE solution, threshold encryption (Shutter Network is working on this technology), etc. The more complex the solution, the simpler the calculation of the transaction becomes.
It is important to note that we need to protect MEV, not eliminate it. Research by @tarunchitra summarizes two main directions for reducing MEV: reducing miners’ flexibility to reorder transactions by enforcing ordering rules, and introducing a competitive market for reordering, adding, and/or censoring transactions. However, this paper concludes that neither fairness ordering nor economic mechanisms alone are effective in reducing the MEV of all payoff functions. In some cases, MEV can never be completely eliminated.
When economically justified, the sequencer executes and publishes transaction batches and state roots to the Data Availability (DA) layer; secure state
Trust assumption: The block producer publishes the entire block to the data availability layer for others to download and verify.
Security issue: If some data is not available, the block may contain malicious transactions hidden by the block producer. Even if a block contains non-malicious transactions, hiding these transactions can compromise system security. The sequencer must have transaction data available because Rollup needs to know the network status and account balances.
solution:
Publishing data on Ethereum is currently the most secure but also the most expensive solution (it will be 90% cheaper after protodankshadring is launched, but even with 10x the throughput, it may still be a drop in the bucket for Rollup): All Ethereum Nodes can download and broadcast Rollup transactions. Since Ethereum has a large number of nodes replicating and validating transaction data, it is difficult for the data to disappear or become completely unavailable.
-After danksharding, Ethereum nodes do not download all transaction data, but only partial data using DAS and KZG (similar to Avails solution mentioned below).
-According to the modular concept, it may be more effective for Rollup to publish transaction data to the data availability layer that is only responsible for data availability (Ethereum’s theoretical performance may be slightly worse because in addition to data availability, Ethereum still retains Layer 1’s implementation, see performance comparison of EigenDA and Ethereum below).
Current modular data availability solutions require a trade-off between security and performance. It is difficult to compare data availability security by just one dimension:
-Avail and CelestiaLeverage DAS to ensure data availability; as long as there is adequate sampling, the data is safe. Since data unavailability is easily detected and recovered by a very small number of light clients, light clients can sample and guarantee data availability to a large extent. Without DAS, none of the above would be possible. The degree of decentralization of the data availability layer, i.e. the number of nodes in the network, determines the level of security and distribution of benefits. EigenDA does not use DAS, but uses an escrow proof mechanism to prevent restakers from being lazy. In other words, the data availability operator must periodically compute a function that can only be completed after all required data has been downloaded. There is a penalty if the blob cannot be proven correctly (but it does not need to be stored once the proof is complete).
-Ensure the accuracy of the data replication process (i.e. erasure coding). EigenDA, Ethereum after EIP-4844, and Avail use kzg commitments to guarantee accuracy, but these are computationally intensive. Celestia uses a fraud-proof design. Light nodes must wait for a period of time before confirming that a block has been correctly encoded, thus completing final confirmation from their perspective. (*Celestia may switch to Validity Proofs if Validity Proofs are a better trade-off option)
-data availability layerEconomic security (reorganization and collusion risk): depends on the staking value in the data availability layer, which is 2/3 of the staking value in Avail and Celestia.
-Forward the data availability certificate of the data availability layer to Ethereum.If the data is published to another data availability layer while the settlement contract is still on Ethereum, then we need a bridge contract to verify that the data availability is available in the data availability layer for final settlement.
--Celestias blobstream Verify signatures on data availability certificates from Celestia. The proof is a Merkle root of Layer 2 data signed by a Celestia validator, proving that the data is available on Celestia. This feature is currently on the testnet.
--Avail Use an optimistic approach to verify data availability proofs. Once this proof is published to the bridge contract on Ethereum, a waiting period begins during which the data availability proof is considered valid unless challenged.
--Succinct is working with Avail and Celestia to develop a zk-SNARK-based data proof bridge that makes the attestation process safer and cheaper by validating zk proofs.
--For EigenDA, the decentralizer splits and publishes tasks to EigenDA nodes, then aggregates signatures from the nodes and delivers the data to Ethereum.
Final settlement: final confirmed status
Trust Assumption 1:
After the first valid Rollup block is published on the main chain, a Rollup full node (a node that can fully calculate the state without relying on other proofs) can finalize it at its height because the Rollup full node has The necessary data and computing resources to quickly verify the validity of the block. However, this is not the case for other third parties such as light clients. They rely on validity proofs, fraud proofs, or dispute resolution protocols to trustlessly verify state without independently running a complete copy of the chain.
Security Issue 1:
For ZK Rollups, Layer 1 verifies zero-knowledge proofs and only accepts correct state roots. The difficulty lies mainly in the cost and generation process of zero-knowledge proofs.
Optimistic Rollups, on the other hand, rely on the premise that at least one honest party will quickly submit a fraud proof to challenge any malicious transaction. However, most current fraud proof systems are not yet permissionless, and only a few validators submit fraud proofs.
Solution 1:
Permissionless fraud proof powered by Arbitrum’s BOLD protocol.The main reason fraud proofs are currently permissioned is to protect against latency attacks:
-During the challenge period, any staker other than the proposer can initiate a challenge. The proposer then needs to present his defense to each challenger one by one. At the end of each challenge round, the loser’s stake will be forfeited.
-In a delay attack, a malicious party (or a group of malicious parties) can prevent or delay the results from being confirmed on the Layer 1 chain by launching a challenge and deliberately losing the dispute and staking.
-To solve this problem,BOLD Challenge ProtocolEnsuring that a single honest party in the world can defeat any number of malicious claims ensures that the settlement confirmation time of Optimistic Rollups will not exceed a certain cap.
Witness Chain Can act as a monitor for new Optimistic Rollups to ensure that at least one honest party will challenge the invalid state:
- Mature Rollups such as Arbitrum and Optimism have sufficient intrinsic incentives for third-party providers (such as browsers, Infura-like services, and their foundations) to monitor chain status and submit fraud proofs when necessary. However, new Rollups or AppChains may not have this level of security.
-Witness Chain adopts a unique incentive mechanism, namely Proof of Diligence, to ensure that the monitoring party (verifier) always has the motivation to monitor and verify transactions, thereby ensuring that the status submitted to the main chain is correct. This mechanism ensures that each validator will perform their duties since the rewards received by the validator are specific and independent for each node. In other words, if a validator discovers a bounty, it cannot share it with other validators, ensuring that each node performs independent validation. In addition, Witness Chain allows Rollups to specify customization requirements (such as the number of validators and their geographical distribution, which is provided by the location proof supported by its independent service), so it has a little more flexibility and ensures both security and efficiency. balance between.
* The Watchtower network is also becoming a new layer in the Rollup stack, providing full security for the execution of other related applications such as Rollup security itself, interoperability protocols, notification services, keeper networks, etc. More details will be released in the future.
Trust assumption 2:
The entire settlement process of smart contract Rollups is written using Layer 1 smart contracts. It is assumed that the smart contract logic on the data availability layer is accurate, has no loopholes, and has no malicious upgrades.
Security Issue 2:
The bridging and upgrade of smart contract Rollups are controlled by the multi-signature wallet. Bridges can be used to steal user funds at will through malicious upgrades.
Solution 2:
The most common idea at the moment is to add a time delay. If the user does not agree with the planned upgrade, he or she can exit. However, this solution requires users to constantly monitor the chain on which all their tokens are located, in case they need to exit.
Altlayers Beacon Layer can serve as the social layer for all Rollups and provide upgrade services.Regardless of whether the bridge contract on Ethereum is upgraded or not, a sequencer running Rollup together with the beacon layer Rollup validator can socially fork Rollup.
Long term: Enshrined Rollup has been the end goal of the Ethereum roadmap for years.In addition to enshrine the bridging/fraud proof validator on Layer 1, it also enshrines the settlement contract.
-Ethereum PSE is working in this direction.
As for sovereign Rollup, the main difference is that the chain state is settled by Rollup full nodes instead of smart contracts in Layer 1. For a more detailed comparison, please refer tohttps://www.cryptofrens.info/p/settlement-layers-ethereum-rollups
It should be noted that improved security does not mean improved performance. Often, the addition of security measures comes with a trade-off for scalability. Therefore, balancing the relationship between the two is crucial. In short, Rollup provides the flexibility to choose different levels of security assumptions based on personal preference. This adaptability is a distinguishing feature of the modular world, allowing tailor-made solutions to specific needs while maintaining system integrity.
Balance customizability and interoperability
There is a well-known adage in the modular world: Modularism, not maximalism. (Modularism, not maximalism.) If Rollup cannot interoperate safely and efficiently, then modularity is not maximalism, but Fragmentation. In view of this, interoperability between different Rollups must be addressed.
First, lets review how monolithic chains achieve interoperability. In short, cross-chain operations are achieved by verifying the consensus or status of other chains. Various approaches are currently on the market, differing in who is responsible for the 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, zero Proof of knowledge, etc.). If you want to learn more about this topic, check out my favorite bridge article: Thoughts on Interoperability.
With the rise of modularity, interoperability issues become more complex:
Fragmentation problem:
The rollup surge is expected to significantly exceed Layer 1 volumes because it is much easier to deploy on Layer 2 than on Layer 1. Will this lead to a highly fragmented network?
While a monolithic blockchain provides consistent consensus and state for simple verification, if a modular blockchain has three (perhaps even four) different components (data availability, execution, settlement, and ordering), the verification process will What is it like?
Data availability and settlement layers become primary data sources. Since Rollup itself provides execution proof, execution verification is already available. Sorting occurs before publishing to the data availability layer.
Scalability issues:
As new rollups are introduced, a question arises: Can we provide bridging services in time to accommodate the new rollups? Even if building a Rollup doesnt require a license, you might still need to spend 10 weeks convincing someone else to add a Rollup. The current bridging service is mainly for mainstream Rollups and tokens. There may be a large influx of rollups in the future, and there are concerns about whether these services can effectively evaluate and launch corresponding solutions to support these new rollups without compromising security and functionality.
User experience issues:
The final settlement of Optimistic Rollup takes seven days, which is much longer than other Layer 1. The challenge now is how to get around the seven-day wait time for the official Optimistic Rollup bridge. There is also a time delay in the submission of zero-knowledge proofs, because Rollup usually waits to accumulate a large number of transactions before submitting the proof to save verification costs. Popular rollups like StarkEx typically publish proofs to Layer 1 only every few hours.
To save costs, rollup transaction data is submitted to the data availability/settlement layer with a time delay (as mentioned above, 1-3 minutes for Optimistic Rollup and several hours for zk Rollup). This needs to be abstracted away for users who want faster and more secure end results.
The good news is that some new solutions have emerged to address these challenges:
Fragmentation problem:
Although there are endless rollups in the ecosystem, it is worth noting that most smart contract rollups currently share a common settlement layer, that is, Ethereum. The main difference between these Rollups is their execution and ordering layers. To achieve interoperability, these rollups only need to mutually verify the final state of the shared settlement layer. However, with sovereign rollups, the situation is slightly more complicated. Due to different settlement layers, sovereign Rollup has certain challenges in achieving interoperability. One way to solve this problem is to establish a peer-to-peer (P2P) settlement mechanism, where each chain directly embeds the light client of the other chain, promoting mutual verification. Alternatively, these sovereign rollups could first be bridged to a centralized settlement center and then serve as a transit point to connect other chains. This centralized approach simplifies the process and ensures tighter interconnection between different Rollups. (Similar to the state of Cosmos interop)
In addition to Ethereum, other potential settlement centers include Arbitrum, zkSync, and StarkNet to serve as settlement centers for Layer 3 built on top of them. Polygon 2.0s interop layer also serves as the central hub for zk Rollup built on top of.
In summary, although the number of rollups and their variants is increasing, the number of settlement centers is still limited. This effectively simplifies the topology and reduces the fragmentation problem to a few key centers. Although there will be more Rollups than the Layer 1 replacements, since Rollups are generally in the same trust/security scope, the interaction between Rollups is simpler than the interaction between Layer 1s.
The interoperability between different settlement centers can refer to the current interoperability method between single chains mentioned earlier.
* Additionally, to eliminate fragmentation issues on the user side, some Layer 2s, including ZKSync, have integrated native account abstractions for a seamless cross-Rollup experience.
scalability issues
Hyperlane (providing modular security for modular chains) and Catalyst (permissionless cross-chain liquidity) emerged 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 these chains naturally interoperable.
Catalyst aims to provide permissionless liquidity to modular chains. Catalyst acts as a bridge, allowing all new chains to seamlessly connect liquidity and exchange with major hubs like Ethereum and Cosmos.
Rollup SDK/RAAS providers provide native bridging services within their ecosystem
Currently, 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 a shared bridging standard that allows assets to move seamlessly between everything sharing the OP Stack code base. For Rollups launched through Altlayer, they are encapsulated into the beacon layer, which acts as a settlement center and ensures secure interoperability. Rollups via Sovereign Labs or zksync, on the other hand, rely on proof aggregation to directly interoperate with each other (explained in more detail later).
User experience issues:
Before we dive into this section, let’s first understand the different levels of commitment and their time delays:
Some participants are satisfied with the first phase of Layer 2 pre-commitment. For example, exchanges like Binance only need to wait for a certain number of Layer 2 blocks before the transaction is considered confirmed, without waiting for the batch to be submitted to Layer 1.Bridging providers such as Hop Protocol acquire 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 Layer 2 to Layer 1, this time may be too long (anywhere from a few hours to 7 days).
The benefits of shortening Phase 2 or Phase 3 are clear, providing users with a safer, faster experience and stronger guarantees in less time. Furthermore, achieving trust-minimized bridging has always been a desirable goal, especially given the frequent occurrence of bridging security incidents.
Shorten the final settlement time (7 days for Optimistic Rollup and hours for zk Rollup), i.e. shorten the third phase
Hybrid Rollup (Fraud Proof + Zero Knowledge): This method combines the advantages of zero-knowledge proofs and Optimistic Rollup. While generating and verifying proofs can be resource intensive, they are only performed when a state transition is challenged. Instead of issuing zero-knowledge proofs for each batch of transactions, proofs are only computed and issued when a proposed state is challenged, similar to Optimistic Rollup. This shortens the challenge period because fraud proofs can be generated in one step and saves the cost of zero-knowledge proofs in most cases.
-It’s worth noting that Eclipse’s SVM Rollups and LayerN leverage isc 0 to generate zero-knowledge fraud proofs. OP Stack already supports Risc 0 and Mina for the development of zero-knowledge fraud proofs. Additionally, Fuel recently introduced a similar hybrid approach that supports multiple provers.
After publishing the data to the data availability layer, do some additional verification of the correctness of the execution to increase confidence - this is a high requirement, the same as with a full node.
-When the sorter batches transactions to Optimistic Rollups data availability layer, it ensures normalized ordering and data availability of x-rollup transactions. Therefore, the only confirmation required is to execute: S 1 == STF(S 0, B 1). Of course, you could just run a full node (which is a tall order) 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 reliable confirmation for both dApps and users.
-Altlayer has a beacon layer between Rollup and Layer 1. The orderer of the beacon layer is responsible for ordering, execution and generating proof of validity (POV). Validity proofs allow the verifier to later verify a Rollups state transitions without accessing the entire state. With regular checks by decentralized validators, we achieve highly robust transaction finalization. There is no need to wait 7 days as validators have already completed the necessary checks, allowing for faster and more secure delivery of cross-chain messages.
-EigenSettle guarantees verification through economic mechanisms. Opt-in EigenLayer nodes perform calculations to ensure the validity of the state and back their commitments with collateral. As long as the amount is lower than the staking amount issued by these operators, it can be considered a safe settlement and achieve economically supported interoperability.
Instant verification using ZK Rollup:
-Sovereign Labs and Polygon 2.0 have taken an innovative approach to bypass the settlement layer to achieve fast finalization. We can immediately propagate the generated zero-knowledge proof through the peer-to-peer network and perform cross-chain operations based on the propagated zero-knowledge proof without waiting for the proof to be submitted to Ethereum. We can then leverage recursion to combine them into batch proofs and submit them to Layer 1 when economically feasible.
--Nonetheless, we still need to believe in the correct aggregation of zero-knowledge proofs. Polygon 2.0’s aggregator can operate in a decentralized manner, allowing Polygon validators from a shared validator pool to participate, increasing the network’s effectiveness and censorship resistance. However, since aggregating zero-knowledge proofs from multiple chains is obviously faster than waiting for enough zero-knowledge proofs on a single chain, this approach will also reduce finalization time.
-Zksync’s Hyperblockchain utilizes a layered approach to aggregating zero-knowledge proofs, resulting in shorter finality times. Instead of settling on Layer 1, Hyperchain can settle its proofs on Layer 2 (becoming Layer 3). This approach facilitates the rapid delivery of messages as the cost-effective environment in Layer 2 enables fast and cost-effective verification.
--To further improve scalability, we can replace Layer 2 settlement with the minimal program required to run Layer 3 and messaging. This concept has been proven through specialized demonstrations that aggregation can be achieved.
Address the time delay in publishing data to the data availability layer (some methods can also be used to shorten the settlement cycle), i.e. shorten the second stage
Shared ordering layer: If a Rollup shares an ordering layer (for example, through a shared orderer service or using the same set of ordering layers), the Rollup can get soft acknowledgments from the sequencer. Combined with economic mechanisms, this approach ensures the integrity of the final state. Possible combinations include:
- Stateless shared sequencer + builder proposed by Espresso makes execution commitments via staking. This approach is more suitable for Rollups with PBS structures, provided that the block builder already has the necessary permissions for some blocks. Since the builder is stateful and acts as the base execution for the shared sequencer, it naturally makes additional commitments.
-Shared Validity Ordering by Umbra Research: Stateful shared ordering + fraud proofs work together to ensure good behavior. The sequencer accepts cross-chain requests. To prevent dishonest behavior by the sequencer, a shared fraud-proof mechanism is adopted, which is a slight modification of the original Rollup fraud-proof mechanism. During the challenge, the challenger will also verify that the atomic operations are executed correctly. This may require checking the root of the bridge contract on a different Rollup or checking the Merkle proof provided by the sequencer. Dishonest sequencers will be punished.
Third party intervention:External entities such as Hop, Connext and Across can step in to mitigate risks. These third parties verify messages and provide financial support for users’ cross-chain financial activities, effectively shortening waiting times. For example, Axelar and Squid’s special feature Boost (GMP Express) can reduce cross-chain transaction times for less than $20,000 to 5-30 seconds.
Intent Infrastructure public chain for bridging as a specific form of third-party intervention:This improved infrastructure can absorb more third-party intervention and solve users cross-domain intentions.
-Through intent-focused architecture (which removes friction and complexity for users by introducing complex actors like market makers and builders), users express their intended goals or outcomes without having to elaborate The precise transactions required to achieve such goals or results. Individuals with a high risk tolerance can step in, take out the necessary funds, and charge higher fees.
-This way is more secure as user funds will only be released if the result is valid. This approach is faster and more flexible because more parties (solvers) participate in the solution process without permission and compete with each other to provide better results for the user.
- UniswapX, Flashbots’ SUAVE and Essential are all working in this direction. For more information on intentions, see: https://www.odaily.news/post/5191537
-The challenge with this solution is the settlement oracle. Taking UniswapX as an example, in order to facilitate cross-chain transactions, we need settlement oracles to determine when funds will be released to solvers. If the settlement oracle chooses to use a native bridge (which is slow), or a third-party bridge (which raises trust issues), or even a light client bridge (which is not yet mature), we will find that we are still stuck in the same cycle. Therefore, UniswapX also provides a fast cross-chain exchange function similar to Optimistic bridging.
-Also, the effectiveness of intent resolution depends on competition between solvers. Since the solver needs to cross-chain rebalance inventories on different chains, this can lead to problems with solver centralization, limiting the full potential of the intent.
To summarize, there are three solutions to user experience problems:
Harness the magic of zero-knowledge technology:
The main challenge with such a solution lies in the performance of zero-knowledge techniques, including the time required to generate zero-knowledge proofs and the associated costs. Furthermore, when dealing with highly customizable modular blockchains, we have to consider the question: do we have a zero-knowledge proof system that can accommodate various differences?
Use financial penalty options:
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 until the upper limit is reached). Additionally, centralized approaches can only provide limited commitments (such as shared ordering) and rely on builders/orderers to make commitments, which can be limiting and lack scalability.
Trust third parties:
While trusting a third party may introduce additional risks because users must trust the bridge, supporting cross-domain exchanges of intent is a more decentralized form of third-party bridging. However, this approach still faces problems with oracle latency, trust issues, and potential time delays because you have to wait for someone to accept your intentions.
Interestingly, modularity also brings new possibilities for interoperability experiences:
Increased speed through modular components: By breaking down components into smaller modules, users can get faster confirmations from Layer 2 (which may be safe enough for the average user)
Shared sequencers for atomic transactions: The concept of shared sequencers may enable a new form of atomic transactions, such as flash loans. For more details, please see: https://twitter.com/sanjaypshah/status/1686759738996912128
Modular interoperable solutions are rapidly evolving, and all currently have pros and cons. Perhaps the ultimate solution is still some way off, but it’s heartening to see so many people working to create a safer, more connected modular world in response to Rollup’s explosive growth.
cost analysis
One reason for the limited number of existing Rollups compared to using smart contracts is economic factors. Operations through smart contracts adopt a more flexible cost model, in which the main cost is gas fees, while rolling out and maintaining Rollup incurs fixed and variable costs. This cost structure suggests that Rollup is more suitable for applications with high transaction volumes or relatively high transaction fees, as such applications can more effectively spread the fixed costs involved. Proposals aimed at reducing Rollup-related costs (fixed and variable) are therefore crucial. As Neel and Yaoqi explained in their talk at the Ethereum Community Conference (ETHCC), a deeper look at the rollup cost structure can give us a clearer picture:
Using financial models such as discounted cash flow (DCF) analysis can help evaluate the feasibility of rolling out rollups for your application. The formula is:
DCF (Revenue - Expenses) > Initial Investment
Used as a benchmark to determine whether operating income exceeds the initial investment to determine whether a new Rollup can bring economic benefits. If the protocol can successfully reduce operating costs while increasing revenue, it will help the promotion of Rollup. Let’s look at them one by one:
Initial development and deployment costs
Although open source SDKs such as Opstack and Rollkit are available, the initial setup still requires significant time and human resources to install and debug. For example, customization requirements such as integrating virtual machines into SDKs require more resources to ensure that the virtual machines are consistent with the interfaces provided by each SDK.
RAAS services like AltLayer and Caldera can significantly reduce this complexity and workload, reflecting the economic benefits of division of labor.
Recurring expenses/income
Income (++++)
user fee
= Layer 1 data release fee + Layer 2 operator fee + Layer 2 congestion fee
Although some user fees may be offset by expenses, careful review and efforts to reduce such costs are required, as Rollup may become unsustainable if user fees are too high. (Discussed in the Fees section)
Miner Extractable Value (MEV)
MEV is primarily related to transaction value from on-chain and can be increased by improving MEV extraction efficiency or increasing cross-domain MEV.
Partnering with established searchers, promoting competition through Proposer/Builder Separation (PBS) auctions, or leveraging SUAVEs block building service can all optimize MEV capture efficiency.
Both can be leveraged to capture more cross-chain MEV as a shared sequence layer or SUAVE (Shared Memory Pool and Shared Block Building) connects multiple domains.
- According to recent research from Akaki, a shared sequencer is extremely valuable for arbitrage searchers who want to seize arbitrage opportunities on different chains, as it ensures victory in a race that occurs simultaneously on all chains.
-As a multi-domain order flow aggregation layer, SUAVE assists builders/searchers in exploring cross-domain MEVs.
cost(- - - -)
Layer 2 operating fees
Sort by:Comparing between centralized and decentralized sorting solutions can be tricky. In more decentralized solutions like Proof of Efficiency, competition keeps operator margins to a minimum and incentivizes releasing batches as frequently as possible, thereby driving down costs. On the other hand, centralized solutions often have fewer parties involved, which can simplify the process but may not reduce costs to the same extent as decentralized solutions.
implement:In this case, the full node uses a virtual machine (VM)/Ethereum Virtual Machine (EVM) to perform changes to the rollup state by new user transactions.
-Parallel execution can be achieved through optimized alternative virtual machines (such as Fuel and Eclipses Solana virtual machine), thus improving efficiency. However, if technologies or solutions that are incompatible with EVM are adopted, friction can arise between developers and end users and potential security issues arise. Arbitrum’s Stylus deserves kudos for being compatible with both EVM and WASM (more efficient than EVM).
prove
Prover Market
- In theory, leveraging dedicated prover markets such as Risc 0, =nil and marlin, rather than creating a proprietary centralized or decentralized prover network, can save costs for the following reasons:
- A dedicated certifier market may attract more participants, thereby promoting increased competition and ultimately lowering 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 cheaper services.
- Of course, there are some drawbacks to this approach, including potentially capturing less utility for the token and relying on external parties for performance. Additionally, different zk rollups may have different hardware requirements for the proof generation process. This difference can be a challenge for provers seeking to expand proof operations.
- More information about prover markets and prover networks: https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c 58596
Layer 1 data publishing
Choosing a lower-cost data availability layer outside of Ethereum, or even using a DAC solution, can significantly reduce fees, although this move may impact security (explored further in Security Layers). For gaming and social applications, which are typically low-value but high-bandwidth, scalability may be more important than security.
Using Ethereum as a data availability layer can leverage protodansharing and dansharding to achieve cost efficiencies. In addition, since the blob release fee is set per block and has nothing to do with Rollups utilization of the blob, a balance needs to be struck between cost and latency: although ideally, Rollup will release a complete blob, due to the transaction The arrival rate is low, and completely occupying the blob space will cause excessive delay costs.
Potential solutions: Federated blob release costs for small-scale rollups;
L1 settlement fee
For an Optimistic Rollup, settlement costs are relatively low. After Bedrock, Optimism only pays about $5 per day into Ethereum;
For zero-knowledge settlement, zero-knowledge proof verification is relatively expensive;
Zero-knowledge proof aggregation
- Depending on the underlying proof system, Rollup on Ethereum may cost anywhere from 300,000 to 5 million gas to verify a single proof. But since the size of the proof grows very slowly (or not at all) as the number of transactions increases, Rollup can reduce the cost per transaction by waiting to accumulate a large number of transactions before submitting the proof.
-As mentioned earlier, the interoperability layer of Sovereign Labs and Polygon 2.0 can aggregate proofs from multiple Rollups, and then each Rollup can verify the status of multiple Rollups at the same time, thus saving verification costs. Zksync’s layered structure and proof aggregation further reduce verification costs.
-However, this method does not work when the two domains use the same zero-knowledge virtual machine or a shared proof scheme (zksyncs hyperblockchain uses the same zero-knowledge EVM and the exact same zero-knowledge proof circuit) Optimal; otherwise, performance degradation may occur.
--NEBRA Labs brings economies of scale and composability to proof verification on Ethereum. NEBRA UPA (Universal Proof Aggregator) aggregates heterogeneous proofs in a common way, thereby amortizing verification costs. UPA can be used to combine proofs from different sources to support new use cases.
In summary, the main ways to save rollup costs include:
Aggregate with other Rollups to spread costs or take advantage of economies of scale:
It is worth noting that this aggregation may also be important to achieve interoperability. As mentioned earlier, using a consistent layer or framework between different Rollups can simplify the interaction between Rollups and ensure that information exchange is uninterrupted. This consolidation strategy enhances the integration and unification of Layer 2 infrastructure.
Take advantage of the principle of division of labor by delegating certain tasks to external service providers.
As the number of Rollups increases day by day (meaning you can share costs with more partners), and as more and more Rollup service providers offer more sophisticated services (offering a wider selection of mature upstream service providers), we created Rollup fees are expected to decrease.
Share security
If you wish to achieve a level of security equivalent to the source chain (either in terms of economics or decentralization), just deploy a smart contract or smart contract rollup. If performance can be improved by leveraging some of the security provided by the source chain, there are several shared security solutions available.
Shared security solutions greatly simplify the secure boot process for most protocols or module layers that require initial security. This is significant for the future of the modular world, as more infrastructure/protocols are expected to emerge that facilitate the functionality of the modular world, and more modules will emerge for Rollup beyond data availability, execution, settlement, and sorting. If a Rollup uses a certain module layer (such as data availability) or a service whose security does not meet Ethereum requirements, the overall security of the module chain may be compromised. 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 validators to repurpose their staked $ETH to protect other applications built on the network.
Cosmos’ ICS allows the Cosmos Hub (the “provider chain”) to lend its security to other blockchains (the “consumer chains”) and collect fees in return.
Mesh Security proposed by Osmosis allows token delegators (rather than validators) to re-stake their pledged tokens on the ecological partner chain. This enables bidirectional or multilateral security flows, as each application chain can enhance overall security based on its mcap.
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.
ICS and Mesh Security are both integral components of the Cosmos ecosystem and are designed to promote the security of cross-chain borrowing. These solutions mainly address the security needs of the Cosmos application chain, enabling it to leverage the security of other chains in the ecosystem. Specifically, Cosmos Hubs ICS provides a solution for Cosmos chains that do not wish to bootstrap a set of validators (replicated security), while Mesh Security requires each chain to have its own set of validators but implements a larger Chain governance options.
Babylon, on the other hand, proposes a unique approach to unlocking the potential assets of BTC holders without moving BTC off its native chain. By optimizing the use of Bitcoins scripting language and integrating advanced encryption mechanisms, Babylon provides more security to the consensus mechanisms of other chains, one of which is a shortened unlocking period. On other POS chains, validators holding BTC can lock their BTC on the Bitcoin network and use the BTC private key to sign POS blocks. Invalid behavior such as double signing can leak a validator’s BTC private key and destroy their BTC on the Bitcoin network. Babylon’s second testnet will launch BTC staking functionality.
While Babylon overcomes the limitations of Bitcoin’s lack of smart contract support, Eigenlayer must run on the Turing-complete Ethereum platform. Eigenlayer not only provides economic security for new rollups and chains, but its environment on Ethereum also supports a more diverse AVS. According to Eigenlayers article on programmable trust, the security that Eigenlayer can provide can actually be further broken down into 3 types:
Economic trust:The trust that comes from validators making a commitment and backing it up with financial benefits. This trust model ensures consistency regardless of the number of parties involved. In this case there must be objective penalty conditions that can be submitted and verified on-chain, which often affects re-stakers.
Decentralized trust:The trust that comes with a decentralized network operated by independently operating 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. The cost and complexity required to take advantage of decentralized trust tends to be low.
Ethereum includes trust:Trust Ethereum validators to build and include your blocks while running the consensus software as promised. This can be specifically committed by Ethereum validators (rather than LST re-stakeholders). They run software sidecars to perform additional calculations and receive additional rewards.
Now that we have the security information clear, what can we expect?
ICS and Mesh Security lower the security barrier for Cosmos application chains like neutron, stride, and axelar.
Eigenlayer can be adapted to many of the previously mentioned solutions:
Rollup Security: Relay Network; Monitoring, Ordering, MEV Protection, EigenDA
Rollup interoperability: Eigensettle; bridge
Cost Analysis: Prover Network
For more content waiting to be explored, please check https://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/
Babylon is running a testnet to improve the security level of other POS chains. Its first testnet provides timestamping services to improve security for high-value Defi activities on cosmos chains such as akash, osmosis, and juno.
The core idea behind these shared security solutions is to enhance the capital efficiency of pledged or illiquid assets by introducing additional liability. However, while pursuing higher returns, you should also remain alert to the resulting risks:
Increased complexity creates more uncertainty. Validators may face additional penalty conditions, but these may not have adequate safeguards, which may pose risks.
The solution proposed by Eigenlayer is to set up a veto committee. The committee serves as a trusting entity between stakers, operators, and AVS developers. In the event of a software vulnerability within AVS, stakers and operators will not face penalties as the veto committee can cast a veto vote. While this approach may not be scalable by itself, subjectivity exists if AVS is not strictly tuned to use cases based on untrustworthy attribution behavior, it can still be an important means of initiating risk mitigation strategies at an early stage.
Increased complexity also brings additional burdens. It is difficult for inexperienced validators to determine which service to share security with. Additionally, the initial setup phase may come with a higher risk of errors. Mechanisms should also be put in place to allow “less tech-savvy” validators and stakers to earn higher returns without being limited by their operational capabilities, provided they are willing to accept relatively high risks.
Both Rio Network and Renzo are working to solve this challenge for Eigenlayer by offering a structured approach that carefully selects advanced node operators and AVS services for potential re-staking, increasing security levels, and reducing participation barriers to entry.
Furthermore, as Eigenlayer gains popularity, it is expected to open up new vistas in the field of security financialization. This may help in valuing shared security and the various applications created based on shared security.
One limitation EigenLayer faces is that it cannot scale its system’s capital allocation by competing for yield opportunities in DeFi for the same assets it supports (LST). EigenLayer commoditizes the value of security, providing many primitives with the ability to support this value and enabling re-stakers to re-stake and participate in the larger DeFi ecosystem.
Ion Protocol attempts to achieve this goal in order to expand the reach of restaking. Ion is building a price-agnostic lending platform that uses zero-knowledge infrastructure to support such assets (zero-knowledge state proof system + ZKML), thereby avoiding the low-level penalty risk present in such assets. EigenLayer commoditizes the basic value of security, which may be the beginning of the birth of many new DeFi primitives, further enhancing the ability of re-staking to expand throughout the ecosystem.
On the cusp of significant change, we must embrace the principles of security, interoperability and cost-effectiveness. These pillars will not only point the way to the development of more scalable and efficient blockchain solutions, but will also lay the foundation for a more connected and accessible digital world. If we embrace these changes with foresight and adaptability, then we will surely create breakthrough progress in the blockchain ecosystem.
