The neglected modular field of aggregate settlement and execution layer

Original title: "Aggregation, settlement, execution" Author: Bridget Harris   Compiler: Chris, Techub News

In terms of attention and innovation, the various parts of the modular stack are not the same. Although many projects have innovated on data availability (DA) and sorting layers before, it was not until recently that the execution layer and settlement layer were taken seriously as part of the modular stack.

Competition incentives in the shared sorter field, Espresso, Astria, Radius, Rome, and Madara are competing for market share. In addition, there are RaaS providers like Caldera and Conduit, which develop shared sorters for Rollups built on 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 obtain the fees it generates.

The sorter market is unique compared to the data availability (DA) space. The data availability (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, “there are several competitors for each service.” I believe that the execution and settlement (and aggregation) layers are relatively underexplored, but they are beginning to iterate in new ways to better align with the rest of the modular stack. Execution and Settlement Layer Relationship The execution and settlement layers are closely connected, with the settlement layer being the place where the state is defined and the final results of the execution are executed. The settlement layer is also able to provide enhancements to the results of the execution layer, thereby enhancing the functionality and security of the execution layer. In practice, this means that the settlement layer can play a variety of roles, such as resolving fraud disputes in the execution layer, verifying evidence, and connecting other execution layer environments.

It is worth noting that some teams choose to directly support the development of custom execution environments in the native environment of their own protocols, such as Repyh Labs, who are building an L1 called Delta. This is essentially a reverse design of the modular stack, but still provides flexibility and has the advantage of technical compatibility because the team does not need 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 the cost is too high.

Other teams choose to build L1s for specific core functions or applications. Hyperliquid is an example of a dedicated L1 built for its flagship native application (a perpetual contract trading platform). Although their users need to perform cross-chain operations through Arbitrum, their core architecture does not rely on the Cosmos SDK or other frameworks, so it can be iteratively customized and optimized for their main use cases.

Execution Layer Progress

In the last cycle, the only feature that general-purpose alternative Layer1s (alt-L1s) had over Ethereum was higher throughput. This meant that projects that wanted to significantly improve performance essentially had to choose to build their own Layer1 from scratch, mainly because Ethereum itself did not yet have the technology. Historically, this simply meant embedding efficiency mechanisms directly into the general-purpose protocol. In the current cycle, these performance improvements are being achieved through modular design and are being implemented on Ethereum, the primary smart contract platform. This allows both 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 virtual machines (VMs) 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 both general-purpose Rollup nodes (e.g. SolanaVM, MoveVM, etc. as execution environments) and application-specific Rollup nodes (e.g. perpetual DEX, order book DEX) on top of their shared state machine. They are also working on enabling 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 typically the "communication overhead" problem for cryptocurrencies. Each xVM can also use a different database architecture, whether it's RocksDB, LevelDB, or a custom sync/async database created from scratch. Interoperability works in part through a "snapshot system" (an algorithm similar to the Chandy-Lamport algorithm) where chains can asynchronously transition to new blocks without the system pausing. On the security side, 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 leverages the Move language for VM/execution, which was originally designed by Facebook and used in networks such as Aptos and Sui. Move has structural advantages over other frameworks, mainly in terms of security and developer flexibility. Historically, the two main issues with building on-chain applications using existing technologies have been security and development flexibility. Importantly, developers can also just write Solidity and deploy on Movement. To achieve this, Movement has 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 notably lack EVM compatibility).

MegaETH is also pushing the envelope 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, which makes L2 performance even better (if the contract is more compute-intensive, the program can get a big speedup, if it’s not very compute-intensive, you can still get ~2x+ speedup).

• Relatively centralized block production, but decentralized block verification and validation.

• 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 to their local database.

• Merkle tree update structure, 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 do not have to go to disk, just to memory.

Another design that has been explored and iterated on recently 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 look at the aggregation layer as a whole and its history and current trends in the crypto space.  

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’s 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 accounts for only a small 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 capitalization is currently around $250 million. In comparison, platforms such as Aave (~$1.4 billion) and Compound (~$560 million) have higher valuations. The situation in traditional financial markets is similar. For example, ICE (Intercontinental Exchange) US and Chicago Mercantile Exchange Group each have a market capitalization of approximately $75 billion, while "aggregators" like Charles Schwab and Robinhood have market capitalizations of approximately $132 billion and approximately $15 billion, respectively. In Schwab, which routes through numerous venues like ICE and CME, the proportion of volume routed through them is disproportionate to their market cap share. Robinhood does about 119 million options contracts per month, while ICE does about 35 million — and options contracts aren’t even a core part of Robinhood’s business model. Despite this, ICE is valued on the public market at about 5x more than Robinhood. So, as application-level aggregation interfaces that route customer order flow to various venues, Schwab and Robinhood are not valued as highly as ICE and CME, despite their large volumes.  

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, this is obviously a different architecture, and I’m curious to see how it plays out. One example is Polygon’s AggLayer, where developers can easily connect their L1 and L2 into a network that aggregates proofs and enables a unified liquidity layer between chains using CDK. This 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 Chain, Avail Rollup, Celestia Rollup, 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, and they can aggregate between different proof systems. For example, aggregating 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, "last mile" settlement becomes easier because Nebra handles all 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 works with proof aggregation. They leave the execution part to the Rollup itself, which runs the execution layer software on a given namespace on the shared sorter, which is essentially just an "execution API", a way for the Rollup to accept sorting layer data. They could also easily add support for proofs of validity 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 #2 → #3, and protocols like Nebra act as the last mile #3 → #4 (execution of 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 retaining only upper-layer applications can lead to incentive issues and high user adoption costs if they don’t control the underlying stack. On the other hand, as competition and technological advances continue to drive down infrastructure costs, it becomes cheaper for applications/application chains to integrate with modular components. I believe this dynamic will be stronger, at least for now.

With all of these innovations (execution layer, settlement layer, aggregation layer), greater efficiency, easier integration, stronger 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.