Modular stack is not only DA and sorting layer worth paying attention to.

Author: Bridget Harris

Compiled by: Luffy, Foresight News

In terms of attention and innovation, the various components of the modular stack are not all the same. While many projects have innovated in the data availability (DA) and sorting layers in the past, it is only recently that the execution and settlement layers have been given attention as part of the modular stack.

Competition in the shared sorter field incentivizes projects such as Espresso, Astria, Radius, Rome, and Madara to compete for market share. In addition, there are RaaS providers like Caldera and Conduit, which develop shared sorters for Rollups built on top of them. These RaaS providers can offer more favorable costs for Rollups because their underlying business model does not rely entirely on sorting revenue. Many Rollups also choose to run their own sorters to capture the fees it generates.

Compared to the DA field, the sorter market is unique. The DA field is essentially an oligopoly composed of Celestia, Avail, and EigenDA. This makes it difficult for smaller newcomers to successfully disrupt the field apart from the three major players. Projects either leverage "existing" choices (Ethereum) or choose one mature DA layer based on their own technology stack type and consistency. While using a DA layer can save a lot of costs, outsourcing the sorter part is not a clear choice (from a cost perspective, not security), mainly due to the opportunity cost of giving up sorter revenue. Many still believe that DA will become a commodity, but we see in the cryptocurrency space that the combination of strong liquidity moats and unique (difficult to replicate) underlying technology makes commoditizing a layer in the stack extremely difficult. Regardless of these debates, many DA and sorter products are being launched. In short, "each service has several competitors" for some modular stacks.

I believe that the execution and settlement (and aggregation) layers have not been fully explored relative to the rest of the modular stack, but they are beginning to iterate in new ways to better align with the rest of the modular stack.

Relationship between execution and settlement layers

The execution and settlement layers are closely integrated, with the settlement layer serving as the place to define the final results of state execution. The settlement layer can also add enhanced functionality to the results of the execution layer, making the execution layer more powerful and secure. In practice, this could mean many different things, such as the settlement layer serving to resolve fraud disputes, validate proofs, and connect the environments of other execution layers.

It is worth noting that some teams directly support the development of custom execution environments in their own protocols, such as Repyh Labs, which is building an L1 called Delta. This is fundamentally the opposite design of the modular stack, but still provides flexibility within a unified environment and has a technical compatibility advantage, as the team does not have to spend time manually integrating each part of the modular stack. Of course, the downside is that it is isolated from a liquidity perspective and cannot choose the modular layer that best suits your design, and the cost is too high.

Other teams choose to build L1s tailored to a specific core function or application. Hyperliquid is an example, as they have built a dedicated L1 for their flagship native application (perpetual contract trading platform). While their users need to cross-chain from Arbitrum, their core architecture does not rely on Cosmos SDK or other frameworks, allowing for iterative customization and optimization for their primary use case.

Progress in the execution layer

The only thing that generic alt-L1 surpassed Ethereum in the last cycle was higher throughput. This means that if a project wants to significantly improve performance, it basically has to choose to build its own L1 from scratch, mainly because Ethereum itself does not have this technology. Historically, this simply meant embedding efficiency mechanisms directly into the generic protocol. In this cycle, these performance improvements are achieved through modular design and are on the most significant smart contract platform, Ethereum. This allows both existing and new projects to leverage the new execution layer infrastructure without sacrificing Ethereum's liquidity, security, and community moat.

Currently, we are also seeing more and more mixing and matching of different VMs (execution environments) as part of a shared network, providing developers with flexibility and better customization at the execution layer. For example, Layer N allows developers to run generic Rollup nodes (such as SolanaVM, MoveVM, etc. as execution environments) and application-specific Rollup nodes (such as perpetual DEX, order book DEX) on their shared state machine. They are also committed to achieving full composability and shared liquidity between these different VM architectures, which has historically been a difficult on-chain engineering problem to scale. Each application on Layer N can asynchronously pass messages in terms of consensus, which is typically a "communication overhead" problem in cryptocurrencies. Each xVM can also use different database architectures, whether it's RocksDB, LevelDB, or a custom synchronous/asynchronous database created from scratch. The interoperability part works through a "snapshot system" (an algorithm similar to the Chandy-Lamport algorithm), where chains can asynchronously transition to new blocks without the need for system pauses. In terms of security, if state transitions are incorrect, fraud proofs can be submitted. With this design, their goal is to minimize execution time while maximizing overall network throughput.

Layer N

To drive customized progress, Movement Labs utilizes the Move language (originally designed by Facebook and used in networks such as Aptos and Sui) for VM/execution. Compared to other frameworks, Move has structural advantages, primarily in security and developer flexibility. Historically, these have been the two main issues in building on-chain applications using existing technology. Importantly, developers can also write in Solidity and deploy on Movement. To achieve this, Movement has created a fully compatible bytecode EVM runtime that can also be used with the Move stack. Their Rollup M2 utilizes BlockSTM parallelization, allowing for higher throughput while still accessing Ethereum's liquidity moat (historically, BlockSTM was only used for alt L1s like Aptos, which clearly lacked EVM compatibility).

MegaETH is also driving progress in the execution layer, particularly through its parallelization engine and in-memory database, where the sorter can store the entire state in memory. In terms of architecture, they utilize:

• Native code compilation to make L2 performance even better (if the contract is more computationally intensive, the program can achieve significantly accelerated performance, and if the computational intensity is not very high, it can still achieve more than 2x acceleration).
• Relatively centralized block production, but decentralized block validation and confirmation.
• Efficient state synchronization, where full nodes do not need to re-execute transactions, but they need to understand state increments so that they can be applied to their local database.
• Merkle tree update structure (usually updating the tree takes up a lot of storage space), while their method is a new trie data structure that is highly efficient in memory and disk. In-memory computation allows them to compress the chain state into memory, so when executing transactions, they do not need to access the disk, only the memory.

As part of the modular stack, another design that has recently been explored and iterated is proof aggregation: defined as a prover that creates a single succinct proof from multiple succinct proofs. First, let's take an overall look at the aggregation layer and its historical and current trends in the crypto field.

Value of the aggregation layer

From a historical perspective, in the non-cryptocurrency market, the market share of aggregators is smaller than that of platforms:

While I'm not sure if this applies to all cases in the cryptocurrency space, it still holds true for decentralized exchanges, cross-chain bridges, and lending protocols.

For example, the total market value of 1inch and 0x (two major DEX aggregators) is about $1 billion, only a small fraction of Uniswap's market value of about $7.6 billion. The same goes for cross-chain bridges: compared to platforms like Across, cross-chain bridge aggregators like Li.Fi and Socket/Bungee have a smaller market share. Although Socket supports 15 different cross-chain bridges, their total cross-chain transaction volume is actually similar to Across (Socket - $2.2 billion, Across - $1.7 billion), with Across accounting for only a small portion of Socket/Bungee's recent transaction volume.

In the lending space, Yearn Finance is the first decentralized lending yield aggregator protocol, with a current market value of about $250 million. In comparison, platforms like Aave (about $1.4 billion) and Compound (about $560 million) have higher valuations.

The situation is similar in traditional financial markets. For example, the market value of ICE (Intercontinental Exchange) and CME Group is about $75 billion each, while "aggregators" like Charles Schwab and Robinhood have market values of about $132 billion and about $15 billion, respectively. In Charles Schwab, which routes trades through numerous venues including ICE and CME, the proportion of trades routed through them is disproportionate to their market share. Robinhood has approximately 119 million options contracts per month, compared to ICE's approximately 35 million - and options contracts are not even a core part of Robinhood's business model. Nevertheless, ICE's valuation in the public market is about 5 times higher than Robinhood's. As consumers, we assign lower value to aggregators.

If the aggregation layer is embedded into the product/platform/chain, this may not hold true in the cryptocurrency space. If the aggregator is directly integrated tightly into the chain, this is obviously a different architecture, and I'm curious to see how it will develop. An example is Polygon's AggLayer, where developers can easily connect their L1 and L2 to a network that aggregates proofs and implements a unified liquidity layer between chains using CDK.

AggLayer

The model works similarly to Avail's Nexus interoperability layer, which includes proof aggregation and sorting auction mechanisms, making their DA product more robust. Like Polygon's AggLayer, each chain or Rollup integrated with Avail can interoperate within Avail's existing ecosystem. Additionally, Avail pools ordered transaction data from various blockchain platforms and Rollups, including Ethereum, all Ethereum Rollups, Cosmos chains, Avail Rollup, Celestia Rollup, and different hybrid structures such as Validiums, Optimiums, and Polkadot parachains. Developers from any ecosystem can build on Avail's DA layer without permission, using Avail Nexus for proof aggregation and messaging across ecosystems.

Avail Nexus

Nebra focuses on proof aggregation and settlement, allowing aggregation between different proof systems. For example, aggregating proofs from the xyz system and the abc system, resulting in aggxyzabc (instead of aggregating within the proof system, resulting in aggxyz and agg_abc). The architecture uses UniPlonK, which standardizes the work of validators across a series of circuits, making it more efficient and feasible to verify proofs across different PlonK circuit validations. Essentially, it uses zero-knowledge proofs themselves (recursive SNARKs) to extend the verification part (usually the bottleneck in these systems). For customers, the "last mile" settlement becomes easier as Nebra handles all batch aggregation and settlement, with the team only needing to change API contract calls.

Astria is researching some interesting designs around how their shared sorter works with proof aggregation. They leave the execution part to the Rollup itself, with the Rollup running execution layer software on the given namespace of the shared sorter, essentially just an "execution API" for the Rollup to accept sorting layer data. They can easily add support for validity proofs here to ensure blocks do not violate EVM state machine rules.

Here, products like Astria act as the #1 → #2 process (unordered transactions → ordered blocks), the execution layer/Rollup nodes are the #2 → #3, and protocols like Nebra act as the last mile #3 → #4 (execution blocks → succinct proofs). Nebra could also be theoretically the fifth step, where proofs are aggregated and then verified. Sovereign Labs is also researching concepts similar to the last step, where cross-chain bridges based on proof aggregation are at the core of their architecture.

Overall, some application layers are beginning to have underlying infrastructure, partly because if they don't control the underlying stack, retaining only the upper layer application may bring incentive issues and high user adoption costs. On the other hand, as competition and technological advancements continue to drive down infrastructure costs, the cost of integrating applications/chains with modular components becomes more affordable. I believe this dynamic will become even stronger, at least for now.

With all these innovations (execution layer, settlement layer, aggregation layer), higher efficiency, easier integration, stronger interoperability, and lower costs become possible. All of these will ultimately bring better applications for users and a better development experience for developers. It's a successful combination that can bring more innovation and faster innovation.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。