ABCDE: Thoughts on Public Chain Infrastructure in 2024

Author: Laobai, ABCDE Translation: Shan Ouba, Golden Finance

In the recent primary market, the hottest track is undoubtedly AI, followed by BTC. About 80% of the projects discussed every day are concentrated on these two tracks. Personally, sometimes I can discuss 5 or 6 AI projects a day.

It is foreseeable that the AI ​​bubble will peak in the next few years. With hundreds of new AI projects coming online, the market value of the AI ​​track will skyrocket. Eventually, when the bubble bursts and chaos ensues, the real unicorns that have truly found the intersection of AI and cryptocurrency will emerge, driving this track and the entire industry forward.

Therefore, in the current AI overheated environment, it is worth taking a step back and observing the changes that have taken place in the infrastructure layer, especially the public chain infrastructure track, in recent months. Some new developments in this field are definitely worth discussing. ”

1. Further deconstruction of ETH or monolithic blockchain

When Celestia first introduced the concept of modularization and DA layer, it actually took the market quite a long time to digest and understand it. Now, this concept has been deeply rooted, and various RaaS (Rollup as a Service) infrastructures have proliferated, so that the number of infrastructures> applications> users has reached an exaggerated stage.

In the past few months, there have been different technological advances in the execution layer, DA layer, and settlement layer. Each layer has spawned new technical solutions, and even the concept of the settlement layer is no longer unique to ETH. Let's briefly discuss the representative technologies of each layer.

2. Execution layer

The hottest concept of the execution layer is undoubtedly Parallel EVM, represented by projects such as Monad, Sei, and MegaETH. Existing projects such as FTM and Canto have also begun to plan upgrades in this direction. However, as not all ZK As much as the projects all protect privacy, the projects marked as parallel EVM actually have different technical roadmaps and ultimate goals.

Using one of Sei’s graphs as an intuitive demonstration, it is clear that in the optimistic case, the transition from sequential processing to parallel processing can significantly improve performance.

In the parallel EVM, there are actually several different technical paths.

From the perspective of how transactions are parallelized, there is nothing particularly new in the world. It comes down to the difference between pre-validation and post-validation.

Take Solana and Sui Pre-verification, represented by , requires transactions to explicitly declare which parts of the chain state they modify. This allows for pre-checks before block production to detect any state conflicts (such as accessing the same AMM pool). If a conflict is detected, the conflicting transaction is discarded. Post-verification, also known as optimistic parallelism, is represented by Aptos BlockSTM, which initially assumes that there are no conflicts and includes transactions. Then, after execution, it checks if there are conflicts. Any conflicting transactions are declared invalid, the results are refreshed, and the execution is repeated until all transactions in the block have been executed. Sei, Monad, MegaETH, and Canto use similar solutions. In the primary market, we have also seen parallelization solutions tailored for scenarios involving state conflicts (such as accessing the same AMM pool mentioned earlier). However, from an engineering perspective, these solutions seem relatively complex, and their commercial feasibility is uncertain and is still being evaluated. The emphasis on parallel EVM can also be divided into two schools.

One ​​of them is represented by Monad and Sei, which prioritize parallel transactions as the main scaling method, making parallelization the main narrative.

For example, in addition to optimistic parallel processing, Monad has developed MonadDB specifically for asynchronous I/O to supplement parallel processing.

The other school of thought is represented by Fantom, Solana, and MegaETH, where parallelization is one of the scaling solutions, but not the only one. Parallelization is a secondary narrative, and performance improvements rely more on other technical solutions.

For example, Fantom's Sonic upgrade focuses on the FVM virtual machine with an optimized Lachesis consensus mechanism. Solana's next phase focuses on the modular architecture of the new Firedancer client, optimized network communication mechanisms, signature verification, etc.

MegaETH aims to achieve a real-time blockchain. First, it is built on the high-performance Reth client developed by Paradigm. Then, various aspects such as the state synchronization mechanism of the full node (synchronizing only the state difference instead of all data), the hardware design of the Sequencer (using a large amount of high-performance RAM with storage capacity for state access), etc., are further optimized and enhanced. , Avoid slow disk I/O), improvements in the Merkle Trie data structure, and so on. This comprehensive optimization covers software, hardware, data structure, disk I/O, network communication, and transaction sorting and parallel processing, pushing the performance ceiling of EVM to the limit and approaching the concept of "real-time blockchain".

Third, the DA layer

There has not been a particularly significant technical iteration in the DA layer, so the heat of this track is far less than that of the execution layer. There are only a few major players in the game.

ETH's CallData is upgraded to Blob, and the fees of various Layer 2 solutions have been greatly reduced, making ETH now a "not too expensive" DA.

Interestingly, Celestia's greater impact is that it is the first project to propose the concept of the DA layer after it went online, raising the DA track from a $2 billion FDV (fully diluted valuation) cap to $20 billion, thereby expanding the landscape and imagination space. Many new Layer 2 application chains naturally prefer DA, with Celestia in the lead.

Avail is independent from Polygon, and technically it is more like an "enhanced version of Celestia." For example, it uses Polkadot's Grandpa+BABE consensus mechanism, which theoretically supports more nodes and a more decentralized setting than Celestia's Tendermint. It also supports features that Celestia does not support, such as proof of validity. However, the technical differences are far less important than the ecosystem, and Avail still needs to catch up at the ecosystem level.

EigenDA went live a few days ago with the launch of the EigenLayer mainnet. As one of the projects with the strongest narrative and the best business cooperation in this round, I personally feel that the adoption rate of EigenDA will not be low. In theory, as long as it "feels safe and cheap", not many projects really care whether you use validity proofs or fraud proofs, or whether you support DAS, etc.

Interestingly, it is worth mentioning the following three DAs.

• Near DA - Near is an excellent public blockchain that initially focused on sharding, and it continues to do so. However, in addition to sharding, it has also entered the DA field. It is cheaper than Celestia and supports fast settlement of Layer 2. Chain abstraction - Recently, Near introduced chain signatures, allowing users to sign any on-chain transaction through a single NEAR account. AI — Their founder Illia is one of the eight Transformers, and was famously tapped on the shoulder by Mr. Huang at NVIDIA GTC. They are currently planning to hire AI engineers and will make an announcement about near.ai next month... As a hexagonal warrior, I have also joined the DA track.

• BTC & CKB — Since BTC's first layer does not support smart contracts and direct settlement, almost every BTC EVM second layer solution treats BTC as a DA. The only difference is whether they apply ZK Proof directly to BTC or simply hash the ZK Proof. It's as if not doing so would disqualify them from being called "BTC Layer 2". Recently, new projects have said, "I won't pretend; I won't pretend". I am ETH L2, and DA settlement is done on ETH, but I serve the BTC ecosystem! ”  Quite interesting… The only unconventional scaling solution is RGB++ introduced by CKB. In this framework, CKB acts as a pseudo-DA, and BTC becomes the settlement layer of RGB++ due to its UTXO universal isomorphic bonding technology.

• New DAs — I will mention two innovative DA approaches I came across, but I will not mention specific projects. One integrates DA with AI, acting not only as a high-performance DA but also as a storage layer for AI large models, training data, and training trajectories. The other improves the RS code underlying DAs such as Celestia to provide a more robust network state under unstable conditions, such as a dynamic network with multiple nodes randomly exiting in each round.

Fourth, Settlement Layer

Initially, this layer was almost entirely dominated by ETH. Although DA faces competition from Celestia and there are various L2 solutions for execution, settlement is mainly ETH field. Other chains such as Solana, Aptos, etc. do not have L2 solutions yet. BTC's L2 solutions are either not being used or cannot be used for settlement with BTC. Currently, ETH is almost the only settlement layer you can think of.

However, this is about to change. Several new projects are already moving in the direction mentioned at the beginning of this article. Some old projects are also beginning to transform in this direction, that is, ZK verification/settlement layer-further deconstructing ETH (stealing ETH's business).

Why does this concept appear?

The reason is that running contracts on ETH L1 to verify ZK Proofs is not the best choice in theory.

From a technical point of view, in order to verify the correctness of ZK Proofs, developers need to use Solidity to write verification contracts based on the ZK project and the selected ZK Proof system. This involves relying on multiple cryptographic algorithms, such as supporting different elliptic curves. These cryptographic algorithms are usually very complex, and EVM-Solidity The architecture is not the best platform for implementing these complex cryptographic algorithms. For some ZK projects, the cost of writing and verifying these verification contracts is also quite high.

This has hindered some ZK ecosystems from natively integrating into the EVM ecosystem to a certain extent. Therefore, ZK-friendly languages ​​such as Cario, Noir, Leo, and Lurk can only be verified on their own Layer1 at present. At the same time, the update or upgrade of ETH always involves a "big ship turning around".

From a cost perspective, although most of the "protection fee" paid by L2 is DA fees, ZK contract verification will also incur gas fees. Verification on Ethereum is definitely not a cheap option. Coupled with the occasional surge in Ethereum's gas fees, turning it into a "premium chain", the verification cost is also affected.

As a result, new projects with the concept of ZK verification/settlement layer have emerged. These new projects are still in a relatively early stage, and Nebra is a typical example. Older projects are also moving in this direction, such as Mina and Zen, which have just passed new proposals.

The overall approach of most projects in this track is basically to:

• Support multiple ZK languages

• Support ZK aggregate proofs for increased efficiency and lower costs

• Achieve faster finality times

The ZK settlement layer will likely be closely tied to the decentralized proof market, as just having the technology is not enough; computational power is also needed. We may see some settlement layer projects partnering with proof market projects. Alternatively, settlement layers with computational power may build their own proof markets, while proof market projects with technical expertise may venture into the settlement layer. Ultimately, the market will dictate the path forward.

There are likely to be many articles online on other areas of infrastructure, such as the Oracle and MEV space (OEV) and interoperability (ZK light client network). I won't delve into them here. I'll share what I find new and interesting next time.