The neglected area of modularity: execution, settlement and aggregation layers

Original title: Aggregation, settlement, execution

Original author: Bridget Harris

Original translation: Luffy, Foresight News

In terms of attention and innovation, not all components of the modular stack are created equal. While many projects have previously innovated on the data availability (DA) and sorting layers, it was only recently that the execution and settlement layers were taken seriously as part of the modular stack.

Competition is spurred in the shared sorter space, with many projects such as Espresso, Astria, Radius, Rome, and Madara vying for market share, in addition to RaaS providers such as Caldera and Conduit, which develop shared sorters for Rollups built on top of them. These RaaS providers are able to offer Rollups more favorable fees because their underlying business model does not rely entirely on sorting revenue. There are also many Rollups that choose to run their own sorters to capture the fees it generates.

The sorter market is unique compared to the DA space. The DA space is essentially an oligopoly consisting of Celestia, Avail, and EigenDA. This makes it difficult for smaller new entrants outside of the big three to successfully disrupt the space. Projects either leverage the "existing" choice (Ethereum); or choose one of the mature DA layers based on the type and consistency of their own technology stack. While there are significant cost savings in using the DA layer, outsourcing the sorter part is not an obvious choice (from a fee perspective, not security), mainly because of the opportunity cost of giving up sorter revenue. Many also believe that DA will become a commodity, but we see in crypto that super strong liquidity moats combined with unique (hard to copy) underlying technology make it extremely difficult to commoditize a layer in the stack. Regardless of these arguments, there are many DA and sorter products launched. In short, for some modular stacks, “each service has several competitors.”

I think the execution and settlement (and aggregation) layers are relatively underexplored, but they are starting to iterate in new ways to better align with the rest of the modular stack.

Execution and Settlement Layer Relationship

The execution layer and the settlement layer are tightly integrated, where the settlement layer can be used as a place to define the final result of the state execution. The settlement layer can also add enhancements to the results of the execution layer, making the execution layer more powerful and secure. This can mean many different functions in practice, such as the settlement layer can serve as an execution layer to resolve fraud disputes, verify proofs, and connect other execution layers.

It is worth mentioning 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 essentially the opposite design of the modular stack, but still provides flexibility in a unified environment, and has the advantage of technical compatibility because the team does not have to spend time manually integrating each part of the modular stack. Of course, the disadvantage is that it is isolated from a liquidity perspective, unable to choose the modular layer that best suits your design, and too costly.

Other teams choose to build an L1 for a core function or application. Hyperliquid is an example, which built a dedicated L1 for its flagship native application (a perpetual contract trading platform). While their users will need to cross-chain from Arbitrum, their core architecture does not rely on the Cosmos SDK or other frameworks, so it can be iteratively customized and optimized for their primary use cases.

Execution Layer Progress

The only feature that general-purpose alt-L1s outperformed Ethereum in the last cycle was higher throughput. This meant that if projects wanted to significantly improve performance, they essentially had to choose to build their own L1 from scratch, mainly because Ethereum itself did not have this technology yet. Historically, this simply meant embedding efficiency mechanisms directly into the general-purpose protocol. In this cycle, these performance improvements are achieved through modular design, and on Ethereum, the most dominant smart contract platform. This allows existing and new projects to take advantage of the new execution layer infrastructure without sacrificing Ethereum's liquidity, security, and community moat.

Currently, we are also seeing an increasing mix and match of different VMs (execution environments) as part of a shared network, which provides developers with flexibility and greater customization on the execution layer. For example, Layer N allows developers to run general-purpose Rollup nodes (such as SolanaVM, MoveVM, etc. as execution environments) and application-specific Rollup nodes (such as perpetual DEX, order book DEX) on top of its shared state machine. They are also working on achieving full composability and shared liquidity between these different VM architectures, an on-chain engineering problem that has historically been difficult to accomplish at scale. Each application on Layer N can asynchronously pass messages without delay in consensus, which is often the "communication overhead" problem of cryptocurrencies. Each xVM can also use a different database architecture, whether it is RocksDB, LevelDB, or a custom synchronous/asynchronous database created from scratch. Interoperability works in part through a "snapshot system" (an algorithm similar to the Chandy-Lamport algorithm), where the chain can asynchronously transition to a new block without the system pausing. In terms of security, fraud proofs can be submitted if the state transition is incorrect. With this design, their goal is to minimize execution time while maximizing overall network throughput.

Layer N

To drive advancements in customization, Movement Labs leveraged the Move language (originally designed by Facebook and used in networks like Aptos and Sui) for VM/execution. Move has structural advantages over other frameworks, primarily security and developer flexibility. Historically, these have been two major issues for building on-chain applications using existing technologies. Importantly, developers can also just write Solidity and deploy on Movement. To enable this, Movement created a fully bytecode-compatible EVM runtime that can also be used with the Move stack. Their Rollup M2 leverages BlockSTM parallelization, which allows for higher throughput while still being able to access Ethereum's liquidity moat (historically, BlockSTM has only been used in alt L1s like Aptos, which obviously lacks EVM compatibility).

MegaETH is also pushing the boundaries in the execution layer space, specifically through its parallelization engine and in-memory database, where the sorter can store the entire state in memory. In terms of architecture, they leverage:

· Native code compilation makes L2 performance much better (if the contract is more computationally intensive, the program can get a big speedup, if it is not very computationally intensive, you can still get about 2x+ speedup).

· Relatively centralized block production, but decentralized block verification and confirmation.

· Efficient state synchronization, where full nodes do not need to re-execute transactions, but they need to understand the state delta so that they can apply it to their local database.

· Merkle tree update structure (usually updating a tree takes up a lot of storage space), and their approach is a new trie data structure that is memory and disk efficient. In-memory computing allows them to compress the chain state into memory, so when executing transactions, they don't have to go to disk, just to memory.

Another design that has been recently explored and iterated on as part of the modular stack is proof aggregation: defined as a prover that creates a single succinct proof of multiple succinct proofs. First, let’s take a look at the aggregation layer as a whole and its history and current trends in crypto.

Value of the Aggregation Layer

Historically, in non-cryptocurrency markets, aggregators have had a smaller market share than platforms:

While I’m not sure this is true for all cases in crypto, it holds true for decentralized exchanges, cross-chain bridges, and lending protocols.

For example, 1inch and 0x (two major DEX aggregators) have a combined market cap of ~$1 billion, a fraction of Uniswap’s ~$7.6 billion market cap. The same is true for cross-chain bridges: cross-chain bridge aggregators like Li.Fi and Socket/Bungee have a smaller market share than platforms like Across. While 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), while Across only accounts for a fraction of Socket/Bungee’s recent transaction volume.

In the lending space, Yearn Finance is the first decentralized lending yield aggregation protocol, and its market cap is currently around $250 million. In comparison, platforms such as Aave (~$1.4 billion) and Compound (~$560 million) have higher valuations.

The situation is similar in traditional financial markets. For example, ICE (Intercontinental Exchange) US and Chicago Mercantile Exchange Group each have a market cap of around $75 billion, while "aggregators" like Charles Schwab and Robinhood have market caps of around $132 billion and around $15 billion, respectively. At Schwab, which routes through numerous venues such as ICE and CME, the proportion of volume routed through them is disproportionate to its market cap share. Robinhood has around 119 million options contracts per month, while ICE has around 35 million - and options contracts are not even a core part of Robinhood's business model. Despite this, ICE is valued on the public market at around 5 times higher than Robinhood. So, as application-level aggregation interfaces, Schwab and Robinhood route customer order flow to various venues, and despite their large volumes, valuations are not as high as ICE and CME.

As consumers, we place less value on aggregators.

This may not be true in crypto if the aggregation layer is embedded into the product/platform/chain. If the aggregator is tightly integrated directly into the chain, it is obviously a different architecture and I am curious to see how it will develop. One example is Polygon’s AggLayer, which allows developers to easily connect their L1 and L2 into a network that aggregates proofs and enables a unified liquidity layer between chains using CDK.

AggLayer

The model works similarly to Avail’s Nexus interoperability layer, which includes proof aggregation and ordering auction mechanisms, making its DA product more powerful. Like Polygon’s AggLayer, every chain or Rollup integrated with Avail can interoperate within Avail’s existing ecosystem. In addition, Avail pools ordered transaction data from various blockchain platforms and Rollups, including Ethereum, all Ethereum Rollups, Cosmos chains, Avail Rollups, Celestia Rollups, and different hybrid structures such as Validiums, Optimiums, and Polkadot parachains. Developers from any ecosystem can build permissionlessly on top of Avail’s DA layer while using Avail Nexus, which can be used for proof aggregation and messaging across ecosystems.

Avail Nexus

Nebra focuses on proof aggregation and settlement, which can aggregate between different proof systems. For example, aggregate the xyz system proof and the abc system proof so that you have agg_xyzabc (rather than aggregating within the proof system so that you have agg_xyz and agg_abc). The architecture uses UniPlonK, which standardizes the work of verifiers for families of circuits, making it more efficient and feasible to verify proofs across different PlonK circuits. Essentially, it uses zero-knowledge proofs themselves (recursive SNARKs) to scale the verification part (usually the bottleneck in these systems). For customers, the "last mile" settlement becomes easier because Nebra handles all the batch aggregation and settlement, and the team only needs to change the API contract call.  

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

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

Overall, some application layers are starting to own the underlying infrastructure, in part because if they don’t control the underlying stack, then retaining only upper-layer applications may bring incentive issues and high user adoption costs. On the other hand, as competition and technological progress continue to drive down infrastructure costs, it becomes cheaper for applications/appchains to integrate with modular components. I believe this dynamic will be more powerful, at least for now.

With all of these innovations (execution layer, settlement layer, aggregation layer), greater efficiency, easier integration, greater interoperability, and lower costs become possible. All of this ultimately leads to better applications for users and a better development experience for developers. It's a winning combination that leads to more innovation, and faster innovation.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia