Editor's note:
Modular blockchain has become one of the development trends identified by crypto community members, including investment institutions such as A16Z, in 2024. At the same time, the Ethereum Cancun upgrade is imminent, and there are many discussions in the community about modular blockchain and monolithic blockchain technology. After comparing and analyzing the underlying technical architecture of Ethereum 2.0 with Near and Polkadot, LBank believes that modular blockchains and monolithic blockchains should not be regarded as adversarial, but as complementary, modular chains can be used as middleware for monomer chains, and monolithic chains can be used as specific layers of modular chains. They learn from each other Xi each other's strengths and weaknesses, and grow together. BlockBeats compiled the original text as follows:
TL; DR
This article is a sequel to our previous research and is titled Opportunities in Modular Storytelling. In that article, we delved into the wave of modularity fueled by Ethereum and Celestia and identified various opportunities.
It's worth noting, however, that modular storytelling shouldn't limit our perspective. Over the past few years, blockchain technology has made significant progress, with the emergence of monolithic and modular blockchain architectures.
In this article, we will first analyze these two architectural approaches and compare Ethereum to other Ethereum competitors from the previous cycle. Surprisingly, there are more similarities between them than one might think.
Next, we explore the challenges and specific considerations associated with these two architectural approaches, while looking ahead to a future where smart contract platforms are symbiotic. In the past, the blockchain ecosystem was dominated by monolithic blockchains, with each new L1 blockchain operating independently, leading to fierce competition and limited collaboration in the market, however, we are now in a stage where chain-to-chain connectivity and interoperability are more developed than ever before. As a result, we prefer an open platform, whether it's modular or monolithic.
All blockchain architectures lead to scaling
This section compares the differences and similarities between Ethereum and other monolithic blockchains in detail, highlighting their differences in architectural design. At the same time, the article discusses the difference between modular design and monolithic architecture, as well as the challenges involved in achieving true scalability.
Although Ethereum itself is modular in design, it also employs sharding as a means of achieving scalability. Sharding allows transactions and data to be processed in parallel across multiple shards, increasing throughput and capacity.
However, the implementation of sharding also comes with its own set of challenges, such as ensuring the availability of data, the finality of transactions, and facilitating cross-rollup transactions. Overcoming these challenges requires careful consideration and innovative solutions to successfully integrate sharding into a monolithic blockchain. Examples of sharding include Ethereum, Near, and Polkadot.
ETH 2.0 与 Near
The past of Nightshade design
The comparison between Ethereum 2.0 (ETH2.0) and Near Protocol focuses on the key differences in their approaches. Ethereum's approach involves rollup-centric sharding, where the execution layer and data availability layer are decoupled. This leverages the underlying L1 to provide security and scalability through rollups.
Near, on the other hand, decided to build a sharded network from the start, taking into account the presence of data sharding and execution sharding in its built-in architecture. This is the first key difference. Ethereum's Rollup hub approach is relatively simple to design, but still requires data availability sharding (Danksharding) for L2 to function efficiently.
The second key difference is clearly explained below. Compared to the common beacon chain and relayer chain, Near has opted for a different sharding solution. Near itself is divided into different shards, each of which is responsible for generating and storing blocks as part of the block.
The so-called "Nightshade" design makes it possible to seamlessly read and write smart contracts between shards, although it puts a higher barrier to entry for developers. For users, they won't even be aware of the shards they're interacting with.
In the modular narrative of the previous article, we discussed solutions to the problem of composability and interoperability. However, this is not a problem for Near, as its built-in sharding essentially allows cross-shard transactions, similar to cross-rollup transactions in L2.
Nightshade's roadmap includes the following phases:
- Stage 0: Simple Nightshade with only one shard;
- Phase 1: Chunk-only producers (editor's note: producers who are solely responsible for generating blocks in a shard (a partition on the network));
- Phase 2: Full Nightshade where there is no validator to keep track of all shards;
- Phase 3: Dynamically adjust the number of shards based on load.
In terms of progress, Near is currently between Phase 1 and Phase 2. Chunk-only producers, introduced last year, can only track the state of one shard. However, there are still full node validators that are responsible for maintaining the global state.
Starsight in progress: ZK-centric sharding
While Near is leading the way in sharding design, it has also learned a lot from Ethereum's revolution. In order to achieve the goals of Phase 2, no validator should keep track of all shards. Instead, the "fisherman" acts as a security guard, monitoring the status and generating evidence of fraud in the challenge. Its core design is very similar to that of Optimistic Rollup, but it's complicated to fully implement it.
That's why many protocols are abandoning this solution. For example, Optimism has moved to the zk solution, and Arbitrum does not allow the submission of unauthorized proof of fraud. Clearly, zkRollups are the future of Ethereum. We can also see the impact of zkRollups in Near's new sharding design.
Stateless verification
What if there was a better solution to eliminate the challenges behind the game? This is where Near introduces stateless validation. Stateless verification generates state verification without handing off state to other shards. With a status witness, there is no longer a need for a "fisherman" or fraud certificate.
In the setup of stateless verification, there are two types of validators. The previous full node validator is now changed to a stateless validator, while the block proposer remains the same. Block proposers are responsible for generating blocks and state witnesses, and they need to maintain the state of the shards locally.
Stateless validators, on the other hand, receive state witnesses to verify the state transitions for each block. By introducing validator rotation, it is almost impossible for a validator to corrupt a shard.
The introduction of stateless verification has a number of benefits. The cost of running a stateless validator is much lower than before, allowing more validators to join the consensus. This increases the degree of decentralization of the entire network. For block proposers, as more shards are added, the state of each shard will be smaller. Since the bottleneck of the blockchain is mainly state reads and writes, the performance of a single shard can be significantly improved if the state is kept entirely in memory.
The magic of zero-knowledge proofs
Prior to the advent of zero-knowledge proofs (ZKPs), state witnesses were traditionally used in MPT. However, as ZKP has matured and recently developed, many protocols, including Near, have actively embraced this transition. ZKP stands out for the simplicity and privacy it provides, significantly reducing the cost of state transition verification. In addition to its compressed data, ZKP is small in size and easy to verify. By utilizing recursive proofs, the state of all shards can be collectively verified.
Sharded proof of state transitions consists of three essential elements: ensuring the correctness of the block hash, confirming the accuracy of the state used during execution, and validating runtime execution. At the moment, there is still a challenge – despite the significant progress made over the past year, the time to generate proofs is still longer than expected.
This is expected to evolve further as the focus on proof systems and engineering capabilities continues to increase. That's why Near partnered with Polygon to build zkWASM.
In order to maintain the current fast determinism without compromising the user experience, Near has been modularized. Starsight has decoupled consensus and execution, enabling consensus to operate independently, deciding which transactions will be included in a block. Remote Procedure Calls (RPCs) provide optimistic finality. Once the proof of a particular state transition is generated, it is submitted to a block, which is subsequently verified by a validator for validity.
The attestation acts as a confirmation of the new state root and the new outgoing receipt root. In this case, a zero-knowledge proof functions similarly to a state witness. However, ZKPs can only be confirmed or rejected by consensus, eliminating the need for validator rotation. ZKP mathematically guarantees correctness and security, and it operates in a very similar way to a rollup that inherits Ethereum's security features.
The modular design can provide additional benefits in a monomer chain. Starsight's flexibility lies in the fact that it works not only with the existing Near WASM runtime, but also with any runtime that can generate zk proofs for state transitions, such as EVM and Move.
ETH 2.0 vs Polkadot
Same design philosophy
The similarities between Ethereum 2.0 and Polkadot have exceeded initial expectations, and the commonality of Gavin Wood's implementations underscores this confirmation. Some have even suggested that Polkadot represents the ultimate goal of ETH 2.0, and while this isn't entirely accurate, the analogy captures a fundamental truth.
From our perspective, Polkadot exhibits a higher level of maturity in engineering implementations. Before zero-knowledge proofs, Ethereum's rollup-centric architecture was tightly aligned with Polkadot's design. A direct comparison of terms can show their striking similarities in terms of their end goals.
Beacon Chain vs. Relay Chain
The Beacon Chain acts as a coordination layer, emphasizing data availability in a rollup-centric approach, the Relay Chain is responsible for message relay and maintaining the data of the parachain, and the shared security is derived from the Relay Chain, and Ethereum positions itself as inheriting security.
Rollup vs. parachain
Parachains are responsible for executing transactions, publishing data on the relay chain, and customizing their own state transitions, while rollups execute transactions outside of L1 and then publish data to L1 and reach a consensus implementation.
The consistent design philosophy is obvious: keep the base layer simple, maintain data availability, coordinate information, and leverage the upper layer to maximize functionality and scalability.
Different strategies and cycles lead to different results
Despite sharing the same design philosophy and moving towards a common goal, the current state of the two blockchains is vastly different. According to Etherscan and Subscan statistics, Ethereum has more than 1 million daily transactions, while Polkadot has only 12,000 in recent days. As for daily active accounts, we see 395,000 on Ethereum and 8,000 on Polkadot.
The difference in their current state is mainly due to their respective strategies. Polkadot pursues the ultimate architecture, deliberately abandoning smart contract functionality. Developers need to build "pallets", or appchain modules, which are a heavy burden for many people. The combination of aggressive strategies and the high barrier to entry for slot auctions has resulted in a lack of vitality in the ecosystem to offset these challenges.
In contrast, Ethereum prioritizes the market and aims to cater to market demand. It adjusts its roadmap accordingly and takes a step-by-step approach.
While we won't delve into the specific reasons for the Ethereum boom and Polkadot's decline, the comparison between ETH 2.0 and Polkadot gives us valuable insights into the future of blockchain architecture and the potential of an open, collaborative ecosystem.
Excellence in abstract concepts and standards
Despite its current challenges, Polkadot has a number of advanced designs to explore and learn from.
An outstanding contribution from the Polkadot ecosystem is the substate framework, which provides a superior abstraction for application chains. The framework enables project parties to easily launch their own chains. Outside of the Polkadot ecosystem, we observe many active chains building on Substrate, including projects like Polygon Avail and Starknet Madara, not to mention numerous independent chains.
While "pallets" can be a technical burden for smart contract developers, they provide powerful abstraction tools for protocol developers. These "pallets" can be reused across all Substrate chains, helping to promote community consensus and standardization efforts. This feature allows for specialization and optimization for specific applications.
Current trends in resource-as-a-service (RaaS), such as the OP stack and Polygon CDK, demonstrate a level of abstraction. However, these open-source repository-like initiatives are still not comprehensive compared to Substrate. As RaaS evolves, we can expect even greater improvements in customization and the availability of chain modules.
Polkadot's second distinguishing feature is Cross-Consensus Message Passing (XCMP), a messaging protocol that enables parachains to exchange arbitrary messages without going through the relay chain. This means that smart contracts can seamlessly call each other within the same parachain and between different parachains.
In contrast, asset bridging and network switching are required when interacting with different rollups on Ethereum. This process presents challenges such as liquidity fragmentation and interoperability disruption. To address these issues, we advocate for the Ethereum Foundation to take a leadership role in the development of standards and actively promote the adoption of these standards across rollups. This approach will significantly contribute to the future development of Ethereum and its associated ecosystem to be more seamless and interoperable.
The last important development for Polkadot is the implementation of an on-chain governance module that effectively transforms Polkadot into a true meta-protocol. This module gives stakeholders the power to vote directly on-chain, deciding the fate of the chain's upgrades. Once a predetermined threshold is reached, the chain will autonomously perform a runtime upgrade. This represents quite a change from Ethereum's main social consensus mechanism today.
Challenges that need to be addressed
The above comparison shows that while there are nuances, the essence of smart contract platforms remains largely the same. As a result, both monolithic and modular blockchains face certain challenges.
In this section, we'll explore two common challenges faced by smart contract platforms as a whole, before diving into the specific issues associated with modular chains.
The key innovation dilemma
One of the main challenges for smart contract platforms is to create a competitive and innovative environment. The popularity of EVM-compatible L1 solutions has become somewhat monotonous, and even Vitalik Buterin categorizes them according to their compatibility.
While acknowledging the historical significance of the groundbreaking EVM and Solidity, it's also critical to recognize that technology has evolved over time. Insisting on the legitimacy and traditional nature of the EVM may limit progress, especially in the face of Ethereum's block limit.
The excitement about different architectures, virtual machines (VMs), and smart contract languages stems from the desire to move away from the limitations of EVMs. The diversity in these aspects attracts developers and users who prefer to work with different programming languages and smart contract features. For instance, in the primary market, Move VM (Aptos, Sui) and Cario VM (Starknet) have received high valuations due to the expectation of innovation and possibility.
When betting on the next innovation platform, it is essential to acknowledge the dominance of the EVM market share. But as the market matures, it tends to fall into a duopoly pattern, as in the case of Android & iOS and Windows & Mac.
WASM is a strong competitor to EVM, with Solana being the biggest player. Despite the criticism, Solana's key innovations, such as the Proof-of-History (POH) clock, Optimistic Concurrency Control (OCC), and the mempool-less transaction forwarding protocol, set it apart from other protocols and break the traditional block design limitations.
How to build broad consensus
The consensus referred to here goes beyond the narrow technical dimension and involves a broad field of social consensus.
From a consensus perspective, it is understandable that many L1 and L2 opt for EVM compatibility. This choice provides them with the easiest way to access the Ethereum ecosystem. However, as the number of EVM chains and rollups increases, the diminishing marginal utility tends to attract ephemeral and disloyal developers and users who may leave quickly after receiving an airdrop.
In addition to EVM compatibility, building consensus through re-staking provides another compelling narrative that engages the existing community. Building from scratch is becoming increasingly complex, emphasizing the importance of choosing the right re-collateralized assets. A subtle but critical point is that the distinction between monolithic and modular block blockchains is reduced by assuming that all modular layers use L1 secure derivatives (LSDs) for security.
Additionally, some protocols extend their reach to a broader group of Web2 users, particularly in the gaming space. Although this method is effective, it requires strong business development efforts. Many traditional players prefer to expand their user base as a means of building consensus in an ever-changing environment.
The specific problem of modular chains
Although modular blockchains efficiently distribute workloads across connected chains or modules, solving specific challenges is critical to achieving true scalability. Key concerns for modular chains include fragmentation, fragility, cross-rollup execution, and centralization.
1. Fragmentation: Fragmentation stems from fierce competition between different layers. Although current competitors may not be working together immediately, the evolution of omnipotent protocols and account abstraction is expected to provide users with a seamless experience across a variety of products;
2. Vulnerability: Vulnerability stems from different security assumptions between different layers. In a modular blockchain, each module operates independently, introducing potential vulnerabilities. When a particular layer encounters a problem, it can affect other integrated layers – an inherent trade-off in the move toward modularity;
3. Cross-Rollup Execution: In modular blockchains, cross-rollup execution is critical to achieving modular blockchain interoperability. The lack of standardized protocols hinders seamless integration between different modules. In addition, the asynchronous execution problem, which is inherent in sharding, must be solved to achieve true scalability of modular blockchains;
4. Centralization: Although the decentralization of Rollups may not be as critical as L1's, it is still an important security issue. Decentralization is necessary to ensure viability, resistance to censorship, and avoiding monopoly advantages. The protocol is actively working to address these issues through solutions such as shard sequencers, abstract boilerplate code, and exposing business logic only to chain developers. Adopting these solutions may help resolve cross-rollup execution issues.
A Collaborative and Inclusive Future
By examining the above two parts, it is clear that modular and monolithic blockchains represent the products of different eras, embodying trade-offs in the impossible triangle and reflecting different philosophical choices.
For years, the crypto space has been stuck in a cycle of monolithic blockchains, with each new L1 building a closed system that prompts fierce zero-sum competition. This environment often leads to extremism as platforms compete for users in their ecosystems.
The advent of modular blockchains has introduced a collaborative and inclusive approach that emphasizes collaboration and interconnection between different chains – a positive development for the industry as a whole. The collaborative approach allows modules to work together seamlessly, enhancing overall functionality and user experience.
In addition, the collaborative nature of modular blockchains fosters the development of innovative and specialized modules. Collaboration and resource sharing between different chains enables developers to focus on domain-specific expertise, resulting in tailored, high-quality modules for specific use cases. In addition, the breakthrough of monomer chains can be decoupled and sequentially merged into the modular layer.
It's crucial not to think of modular blockchains and monolithic blockchains as adversarial, but rather as complementary. They learn from each other Xi each other's strengths and weaknesses, and grow together. The boundaries between them may not be obvious, as a modular chain can serve as middleware for a monolithic chain, while a monomer chain can serve as a specific layer of a modular chain.
Rather than focusing on differences in scope, the focus should shift to nurturing an open network that embraces key innovations and builds broad consensus.