Original author: Bridget Harris
Original translation: Luffy, Foresight News
Not all components of the modular stack are created equal in terms of attention and innovation. While many projects have innovated on the data availability (DA) and ordering layers, only recently have the execution and settlement layers received significant attention as part of the modular stack.
Competition in the shared sorter space is spurred, with many projects such as Espresso, Astria, Radius, Rome, and Madara vying for market share, in addition to RaaS providers like Caldera and Conduit, which develop shared sorters for Rollups built on top of them. These RaaS providers are able to offer Rollups better fees because their underlying business models do 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 “incumbent” 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 from using a DA layer, outsourcing the sorter portion is not an obvious option (from a fee perspective, not security), mainly because of the opportunity cost of forgoing sorter revenue. Many also believe that DAs 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 every service.”
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 serve as the place where the final result of the state execution is defined. The settlement layer can also add enhancements to the results of the execution layer, making the execution layer more powerful and secure. This may mean many different functions in practice, for example the settlement layer can serve as an environment for the execution layer to resolve fraud disputes, verify proofs, and connect other execution layers.
It’s worth noting that some teams are supporting the development of custom execution environments directly within their own protocols, such as Repyh Labs, which is building an L1 called Delta. This is essentially the opposite design of a modular stack, but still provides flexibility in a unified environment and has technical compatibility benefits as teams don’t have to spend time manually integrating each part of the modular stack. Of course, the downsides are isolation from a liquidity perspective, inability to choose the modular layer that best suits your design, and high costs.
Other teams choose to build L1s for a core function or application. Hyperliquid is an example of a dedicated L1 built for its flagship native application (a perpetual contract trading platform). While their users need to cross-chain from Arbitrum, their core architecture does not depend on the Cosmos SDK or other frameworks, so it can be iteratively customized and optimized for its main use case.
Executive Level Progress
The only feature that general-purpose alt-L1s had over Ethereum in the last cycle was higher throughput. This meant that projects that wanted to significantly improve performance essentially had to choose to build their own L1 from scratch, primarily because Ethereum itself didn’t have the technology yet. Historically, this simply meant embedding efficiency mechanisms directly into the general-purpose protocol. In this cycle, these performance improvements are being achieved through modular design, and on Ethereum, the dominant smart contract platform. This allows existing and new projects alike to take advantage of 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, 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 M 2 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 driving advancements 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 even better (if the contract is more compute intensive, the program can get a big speedup, if it is not very compute 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 do need to be aware of state deltas so that they can apply to their local database.
Merkle tree update structure (usually updating the 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.
The value of the aggregation layer
Historically, in non-cryptocurrency markets, aggregators have had smaller market share than platforms:
While I’m not sure this applies to all cases in cryptocurrencies, it does apply to 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 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 value is currently approximately US$250 million. In comparison, platforms such as Aave (approximately US$1.4 billion) and Compound (approximately US$560 million) have higher valuations.
The situation is similar in traditional financial markets. For example, ICE (Intercontinental Exchange) US and CME Group each have market caps of about $75 billion, while “aggregators” like Schwab and Robinhood have market caps of about $132 billion and about $15 billion, respectively. At Schwab, which routes through numerous venues like ICE and CME, the proportion of volume routed through them is disproportionate to their share of market cap. Robinhood has about 119 million options contracts per month, while ICE has about 35 million—and options contracts are not even a core part of Robinhood’s business model. Despite this, ICE is valued about 5x higher than Robinhood in the public markets. Therefore, 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 trading volumes.
As consumers, we assign less value to 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 develops. 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, aggregating a proof of system xyz and a proof of system abc so that you have agg_xyzabc (instead of aggregating within a 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 (which is often 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 calls.
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, essentially just an “execution API”, a way for the Rollup to accept sorting layer data. They could also easily add support for validity proofs here to ensure that blocks don’t violate the EVM state machine rules.
Here, products like Astria act as the#1→#2process (unordered transactions → ordered blocks), 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 core to their architecture.
In general, some application layers are starting to own the underlying infrastructure, in part because if they don't control the underlying stack, then keeping only the upper layer applications may bring incentive problems 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/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, 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