The overlooked modularization areas: aggregation, settlement, and execution layers

Original Title: “Aggregation, settlement, execution”

Author: Bridget Harris

Translation: Chris, Techub News

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

The competition in the shared sorter space is fierce, with many projects like Espresso, Astria, Radius, Rome, and Madara vying for market share. Additionally, there are RaaS providers like Caldera and Conduit that develop shared sorters for Rollups built on their infrastructure. These RaaS providers can offer better fees for Rollups because their underlying business models do not rely entirely on sorting revenue. Many Rollups also choose to run their own sorters to capture the fees they generate.

Compared to the data availability (DA) space, the sorter market is unique. The DA space is essentially an oligopoly dominated by Celestia, Avail, and EigenDA. This makes it difficult for smaller newcomers to disrupt the space outside of the three giants. Projects either leverage "existing" options (Ethereum) or choose one of the mature DA layers based on their own tech stack type and consensus. While using a DA layer can save significant costs, outsourcing the sorting part is not an obvious choice (from a cost perspective, not security), mainly due to the opportunity cost of giving up sorting revenue. Many also believe that DA will become a commodity, but we see in cryptocurrency that a strong liquidity moat combined with unique (hard-to-replicate) underlying technology makes it extremely difficult to commoditize any layer in the stack. Regardless of these debates, many DA and sorter products have been launched. In short, for some modular stacks, "each service has several competitors."

I believe that the execution and settlement (and aggregation) layers have yet to be fully explored, 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 layer and settlement layer are closely linked, with the settlement layer serving as the place that defines state and executes final results. The settlement layer can also provide enhancements for the results of the execution layer, thereby enhancing the functionality and security of the execution layer. In practical terms, this means that the settlement layer can take on multiple roles, such as resolving fraud disputes in the execution layer, verifying evidence, and connecting to other execution layer environments.

Notably, some teams choose to directly support the development of custom execution environments in the native environment of their protocol, such as Repyh Labs, which is building an L1 called Delta. This is essentially a reverse design of the modular stack but still offers flexibility and the advantage of technical compatibility, as the team does not need to spend time manually integrating each part of the modular stack. Of course, the downside is that it is isolated from a liquidity perspective, unable to choose the modular layer that best fits its design, and the costs are too high.

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

Progress in the Execution Layer

In the previous cycle, the only feature where generic alternative Layer1s (alt-L1) outperformed Ethereum was higher throughput. This means that if a project wants to significantly enhance performance, it essentially has to choose to build its own Layer1 from scratch, mainly because Ethereum itself has not yet possessed this technology. Historically, this simply meant embedding efficiency mechanisms directly into the generic protocol. In the current cycle, these performance improvements are achieved through modular design and implemented on the major 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 also see an increasing mix and match of different virtual machines (VMs) as part of a shared network, providing developers with flexibility and better customization on 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 DEXs, order book DEXs) on top of its shared state machine. They are also working towards achieving full composability and shared liquidity between these different VM architectures, which has historically been a challenging on-chain engineering problem to accomplish at scale. Each application on Layer N can asynchronously pass messages with no delay in consensus, which is often a "communication overhead" issue in cryptocurrency. Each xVM can also use different database architectures, whether 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 system pauses. In terms of security, fraud proofs can be submitted if state transitions are incorrect. Through this design, their goal is to minimize execution time while maximizing overall network throughput.

Layer N

To drive customization progress, Movement Labs utilizes the Move language for VM/execution, a language originally designed by Facebook and used in networks like Aptos and Sui. Compared to other frameworks, Move has structural advantages, primarily 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 simply write Solidity and deploy on Movement. To achieve this, Movement created an EVM runtime that is fully compatible with bytecode, which can also be used alongside the Move stack. Their Rollup M2 utilizes BlockSTM parallelization, allowing for higher throughput while still accessing Ethereum's liquidity moat (historically, BlockSTM has only been used in alt L1s like Aptos, which clearly lacks EVM compatibility).

MegaETH is also pushing advancements in the execution layer, particularly through its parallelization engine and in-memory database, where sorters can store the entire state in memory. Architecturally, they leverage:

• Native code compilation, which enhances L2 performance (if the contract is more computation-intensive, the program can achieve significant acceleration; if not very computation-intensive, it can still achieve over 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 they can be applied to their local databases.

• Merkle tree update structures, with their approach being a new trie data structure that is memory and disk efficient. Memory computation allows them to compress chain state into memory, so when executing transactions, they do not have to go to disk, just to memory.

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

Value of the Aggregation Layer

Historically, in non-cryptocurrency markets, the market share of aggregators is smaller than that of platforms:

While I am not sure if this applies to all cases in cryptocurrency, this conclusion still holds for decentralized exchanges, cross-chain bridges, and lending protocols.

For example, the total market capitalization of 1inch and 0x (two major DEX aggregators) is about $1 billion, a small fraction of Uniswap's market cap 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. 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 portion of Socket/Bungee's recent transaction volume.

In the lending space, Yearn Finance is the first decentralized lending yield aggregator protocol, currently valued at about $250 million. In contrast, platforms like Aave (around $1.4 billion) and Compound (around $560 million) have higher valuations.

The situation is similar in traditional financial markets. For instance, the market capitalizations of ICE (Intercontinental Exchange) US and the Chicago Mercantile Exchange Group are each around $75 billion, while "aggregators" like Charles Schwab and Robinhood have market capitalizations of about $132 billion and $15 billion, respectively. In Charles Schwab, which routes trades through numerous venues like ICE and CME, the proportion of trading volume routed through them is disproportionate to their market cap share. Robinhood has about 119 million options contracts per month, while ICE has about 35 million contracts — 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 that of Robinhood. Thus, as application-level aggregation interfaces, Charles Schwab and Robinhood route customer order flow to various venues, even though they have large trading volumes, their valuations are not as high as those of ICE and CME.

As consumers, we assign lower value to aggregators.

If the aggregation layer is embedded into products/platforms/chains, this may not hold in cryptocurrency. If aggregators are tightly integrated directly into the chain, it is clearly a different architecture, and I am curious how it will evolve. One example is Polygon's AggLayer, where developers can easily connect their L1 and L2 into a network that can aggregate proofs and achieve a unified liquidity layer across chains using CDK.

AggLayer

The model works similarly to Avail's Nexus interoperability layer, which includes proof aggregation and sorting auction mechanisms, making its 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 Rollups, Celestia Rollups, and different hybrid structures like Validiums, Optimiums, and Polkadot parachains. Developers from any ecosystem can build permissionlessly on top of Avail's DA layer while using Avail Nexus for cross-ecosystem proof aggregation and messaging.

Avail Nexus

Nebra focuses on proof aggregation and settlement, allowing aggregation between different proof systems. For example, aggregating xyz system proofs and abc system proofs gives you aggxyzabc (instead of aggregating within the proof system, which would give you aggxyz and agg_abc). This architecture uses UniPlonK, which standardizes the work of verifiers across a series 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 (which is often the bottleneck in these systems). For clients, the "last mile" settlement becomes easier, as Nebra handles all batch aggregation and settlement, and teams only need to change API contract calls.

Astria is exploring some interesting designs around how their shared sorter works with proof aggregation. They leave the execution part to the Rollup itself, which runs execution layer software on a given namespace of the shared sorter, essentially just an "execution API," which is a way for the Rollup to accept data from the sorting layer. They can also easily add support for validity proofs here to ensure that 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 node is #2 → #3, while protocols like Nebra act as the last mile #3 → #4 (executed blocks → succinct proofs). Nebra could also theoretically be a fifth step, where proofs are aggregated and then verified. Sovereign Labs is also exploring a similar concept for the last step, where cross-chain bridges based on proof aggregation are central to their architecture.

Overall, some application layers are beginning to possess underlying infrastructure, partly because if they do not control the underlying stack, merely retaining the upper application may lead to incentive issues and high user adoption costs. On the other hand, as competition and technological advancements continue to drive down infrastructure costs, the costs of integrating applications/application chains with modular components have become 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 this ultimately leads to better applications for users and a better development experience for developers. This is a successful combination that can foster more innovation and accelerate the pace of innovation.