Comparing Ethereum 2.0 with Near and Polkadot, interpreting the future of modular blockchain

“The relationship between modular blockchain and single blockchain is complementary rather than confrontational.”

Original title: “Co-exist Future of Smart Contract Platforms”

Written by: FF, LBank Labs Research Team

Compiled by: Sharon, BlockBeats

Editor’s note:

Modular blockchain has become one of the 2024 development trends identified by members of the crypto community, including investment institutions such as a16z. At the same time, the Ethereum Cancun upgrade is imminent, and there are various opinions on modular blockchain and monolithic blockchain technology in the community. LBank recently issued an article giving its own views on this. After comparing and analyzing the underlying technical architecture of Ethereum 2.0 with Near and Polkadot, LBank believes that modular blockchains and single blockchains should not be regarded as antagonistic. , but should be regarded as complementary, the modular chain can serve as the middleware of the monomer chain, and the monomer chain can serve as a specific layer of the modular chain. They learn from each other’s strengths and weaknesses and develop together. BlockBeats compiles the original text as follows:

TL; DR

This article is a continuation of our previous research titled Opportunities in Modular Narratives. In that article, we took a deep dive into the modular wave driven by Ethereum and Celestia and identified the various opportunities.

It is important to note, however, that modular narratives should not 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 people think.

Next, we’ll explore the challenges and specific considerations associated with these two architectural approaches while looking toward a symbiotic future for smart contract platforms. In the past, the blockchain ecosystem was dominated by monolithic blockchains, with each new L1 blockchain operating independently, resulting in fierce competition and limited cooperation in the market; however, we are now in a chain-to-chain Connectivity and interoperability between the stages are more developed than ever before. Therefore, we prefer open platforms, whether they are modular or monolithic.

All blockchain architectures will lead to expansion

This section provides a detailed comparison of the differences and similarities between Ethereum and other monolithic blockchains, highlighting their differences in architectural design. It also discusses the differences between modular design and monolithic architecture, as well as the challenges involved in achieving true scalability.

While Ethereum itself has a modular design, it also uses sharding as a means to achieve scalability. Sharding allows transactions and data to be processed in parallel across multiple shards, increasing throughput and capacity.

However, the implementation of sharding also brings its own set of challenges, such as ensuring data availability, transaction finality, 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 and Near

Nightshade Design’s Past

Comparing Ethereum 2.0 (ETH2.0) and Near Protocol focuses on key differences in their approaches. Ethereum’s approach involves Rollup-centric sharding, where the execution and data availability layers are decoupled. This leverages the underlying L1 to provide security and rollup for scalability.

Near decided to build a sharded network from the beginning, fully considering the existence of data sharding and execution sharding in its built-in architecture. This is the first key difference. Ethereum’s Rollup central method design is relatively simple, but it still requires data availability sharding (Danksharding) to enable L2 to operate efficiently.

The second key difference is clearly explained below. Compared with the common beacon chain and relay chain, Near has chosen a different sharding solution. Near itself is divided into different shards, each shard is responsible for generating and storing blocks as part of the block.

The so-called “Nightshade” design makes it possible to achieve seamless smart contract reading and writing between shards, although this imposes a higher threshold for developers. For users, they won’t even be aware of the shards they are interacting with.

In the previous article’s modular narrative, we discussed solutions to the problems of composability and interoperability. However, this is not a problem for Near because its built-in sharding essentially allows for cross-shard transactions, similar to cross-rollup transactions in L2.

Nightshade’s roadmap includes the following stages:

• Stage 0: Simple Nightshade, only one shard;
• Phase 1: Chunk-only producer (Editor’s note: refers to a producer who is solely responsible for generating blocks in a shard (a partition on the network));
• Phase 2: Full Nightshade, where no validators track 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. The Chunk-only producer introduced last year can only track the status of one shard. However, there are still full node validators responsible for maintaining global state.

Starsight in progress: ZK-centric sharding

While Near leads the way in sharding design, it has also learned a lot from the Ethereum revolution. To achieve the goals of Phase 2, no validator should keep track of all shards. Instead, the “fisherman” acts as a security guard, monitoring status and generating evidence of fraud in challenges. The core design is very similar to Optimistic Rollup, but fully implementing it is complex.

This is why many protocols are abandoning this solution. For example, Optimism has moved to a zk solution and Arbitrum does not allow the submission of unlicensed fraud proofs. Clearly, zkRollups are the future of Ethereum. We can also see the influence of zkRollups in Near’s new sharding design.

Stateless verification

What if there was a better solution to remove the challenge behind the game? This is where Near introduces stateless validation. Stateless verification generates state verification without handing state over to other shards. With a state witness, there is no need for a “fisherman” or proof of fraud.

In a stateless validation setup, there are two types of validators. The previous full node validators are now changed to stateless validators, while the block proposers remain unchanged. Block proposers are responsible for generating blocks and state witnesses, who need to maintain the state of the shard locally.

Stateless validators, on the other hand, receive state witnesses to verify the state transition of each block. By introducing validator rotation, it is almost impossible to have a validator corrupt a shard.

Introducing stateless validation brings many benefits. The cost of running stateless validators 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 become smaller. Since the bottleneck of the blockchain is mainly state reading and writing, the performance of a single shard can be significantly improved if the state is completely kept in memory.

The magic of zero-knowledge proofs

Before the advent of zero-knowledge proofs (ZKP), state witnesses were traditionally used in MPT. However, with the maturity and recent development of ZKP, many protocols, including Near, have actively embraced this transition. ZKP stands out for the simplicity and privacy features it offers, significantly reducing the cost of state transition verification. In addition to its compressed data, ZKP is small and easy to verify. By leveraging recursive proofs, the state of all shards can be verified collectively.

A proof of state transition for a shard consists of three basic elements: ensuring the correctness of the block hash, confirming the accuracy of the state used during execution, and verifying the runtime execution. Currently, one challenge remains – despite significant progress over the past year, generating proofs still takes longer than expected.

This is expected to evolve further as efforts to demonstrate systems and engineering capabilities continue. That’s why Near teamed up with Polygon to build zkWASM.

In order to maintain the current fast certainty without affecting the user experience, Near has made modular adjustments. Starsight has decoupled consensus and execution, allowing consensus to run independently and decide which transactions will be included in a block. Remote Procedure Calls (RPC) provide optimistic finality. Once a proof for a particular state transition is generated, it is submitted into a block and a validator subsequently verifies the validity of the proof.

This proof acts as confirmation of the new state root and the new outgoing receipt root. In this case, zero-knowledge proofs function like state witnesses. However, ZKP can only be confirmed or rejected by consensus, eliminating the need for validator rotation. ZKP guarantees correctness and security through mathematics, and operates very similarly to Rollup, which inherits the security features of Ethereum.

Modular design can provide additional benefits in monolithic chains. The flexibility of Starsight is 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 and Polkadot

Same design philosophy

There are more similarities between Ethereum 2.0 and Polkadot than initially expected, a confirmation highlighted by the commonality of implementations by Gavin Wood. Some have even suggested that Polkadot represents the ultimate goal of ETH 2.0, and while this is not entirely accurate, the analogy captures a fundamental truth.

From our perspective, Polkadot demonstrates a higher level of engineering maturity. Before there was zero-knowledge proof, Ethereum’s Rollup-centric architecture was closely integrated with Polkadot’s design. A direct comparison of terms can reveal striking similarities in their ultimate goals.

Beacon chain and relay chain

As the coordination layer, the beacon chain emphasizes data availability in a rollup-centered manner; the relay chain is responsible for message relay and maintaining the data of the parallel chain. Shared security comes from the relay chain, and Ethereum positions itself to inherit security. sex.

Rollup and Parachain

Parallel chains are responsible for executing transactions, publishing data on the relay chain, and customizing their own state transitions; Rollup executes transactions outside L1, then publishes data to L1 and reaches consensus.

A consistent design philosophy is evident: keep the base layer simple, maintain data availability, coordinate information, and leverage upper layers to fully enhance functionality and scalability.

Different strategies and cycles lead to different results

Despite sharing the same design philosophies and working toward common goals, the current status of the two blockchains differs dramatically. According to statistics from Etherscan and Subscan, Ethereum’s daily transaction volume exceeds 1 million, 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 status is largely due to their respective strategies. Polkadot pursues the ultimate architecture and deliberately gives up the smart contract function. Developers need to build “pallets,” or application chain modules, which is a heavy burden for many. The combination of aggressive strategies and the high threshold for slot auctions results in an ecosystem that lacks sufficient dynamism to offset these challenges.

In contrast, Ethereum prioritizes the market and aims to cater to market needs. It adjusts its roadmap accordingly, taking a step-by-step approach.

While we won’t delve into the specific reasons for Ethereum’s boom and Polkadot’s decline, the comparison between ETH 2.0 and Polkadot provides us with valuable insights into the future of blockchain architecture and the potential of an open, collaborative ecosystem.

Abstract concepts and standards of excellence

Despite the challenges it currently faces, Polkadot has many advanced designs worth exploring and learning from.

An outstanding contribution from the Polkadot ecosystem is the substate framework, which provides an excellent abstraction concept for application chains. This framework enables project parties to easily launch their own chains. Outside of the Polkadot ecosystem, we observe many active chains being built on Substrate, including projects like Polygon Avail and Starknet Madara, not to mention numerous independent chains.

While “pallets” may constitute a technical burden for smart contract developers, they provide powerful abstraction tools for protocol developers. These “pallets” can be reused on all Substrate chains, helping to promote community consensus and standardization efforts. This feature allows specialization and optimization for specific applications.

Current trends in Resource as a Service (RaaS), such as OP stack and Polygon CDK, demonstrate a certain level of abstraction. However, these initiatives like open source repositories are still not comprehensive compared to Substrate. As RaaS evolves, we can expect greater improvements in customization and availability of chain modules.

The second distinctive feature of Polkadot 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 as well as between different parachains.

In contrast, asset bridging and network switching are required when interacting with different Rollups on Ethereum. This process brings challenges such as fragmented liquidity and broken interoperability. To solve these problems, we advocate that the Ethereum Foundation plays a leading role in the development of standards and actively promotes the application of these standards in various Rollups. This approach will significantly contribute to the future development of Ethereum and its related ecosystems to be more seamless and interoperable.

The last major development for Polkadot is the implementation of an on-chain governance module, effectively turning Polkadot into a true meta-protocol. This module gives stakeholders the power to vote directly on the chain and decide the fate of chain upgrades. Once a predetermined threshold is reached, the chain will autonomously perform runtime upgrades. This represents a considerable change from Ethereum’s primary social consensus mechanism today.

Challenges to be solved

The above comparison shows that although there are subtle differences, the essence of smart contract platforms remains basically the same. Therefore, 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 delving into specific issues related to modular chains.

Key innovation dilemmas

One of the main challenges facing smart contract platforms is establishing a competitive and innovative environment. The popularity of EVM-compatible L1 solutions has become somewhat monotonous, even Vitalik Buterin classified them according to their compatibility.

While acknowledging the historical significance of the groundbreaking EVM and Solidity, it is also critical to recognize that technology has evolved over time. Insisting on the legal and traditional nature of the EVM may limit progress, especially in the face of Ethereum’s block limits.

The excitement about different architectures, virtual machines (VMs), and smart contract languages stems from the desire to escape the limitations of the EVM. Diversity in these aspects attracts developers and users who prefer to use different programming languages and smart contract features. For example, in the primary market, Move VM (Aptos, Sui) and Cario VM (Starknet) have achieved high valuations due to the expectations of innovation and possibility they bring.

When betting on the next innovative platform, EVM market share dominance must be acknowledged. But as the market matures, it tends to fall into a duopoly, with Android & iOS and Windows & Mac being examples.

WASM is a strong competitor to EVM, with Solana being the largest player. Despite criticism, Solana’s key innovations, such as the Proof-of-History (POH) clock, Optimistic Concurrency Control (OCC), and mempool-less transaction forwarding protocol, set it apart from other protocols and break with traditional block design limit.

How to build broad consensus

The consensus mentioned here goes beyond the narrow technical level and involves the broad field of social consensus.

From a consensus perspective, it’s understandable that many L1 and L2 opt for EVM compatibility. This option provides them with the easiest way to plug into the Ethereum ecosystem. However, as the number of EVM chains and Rollups increases, diminishing marginal utility tends to attract transient and disloyal developers and users, who may leave quickly after receiving airdrops.

In addition to EVM compatibility, building consensus through restaking provides another compelling narrative to engage the existing community. Building from scratch is becoming increasingly complex, underscoring the importance of choosing the right rehypothecation asset. A subtle but critical point is that assuming all modular layers use L1 Security Derivatives (LSD) to ensure security, the difference between a monolithic blockchain and a modular block blockchain is reduced.

In addition, some protocols extend their influence to a wider group of Web2 users, especially in the gaming field. While this approach is effective, it requires a strong business development effort. Many traditional players prefer expanding their user base as a means of achieving consensus in a changing environment.

Specific issues with modular chains

While modular blockchains efficiently distribute workloads between connected chains or modules, solving specific challenges is critical to achieving true scalability. Key concerns with modular chains include fragmentation, fragility, cross-rollup execution, and centralization.

1. Fragmentation: Fragmentation results from fierce competition between different layers. While current competitors may not collaborate immediately, the evolution of universal protocols and account abstractions is expected to provide users with a seamless experience across various products;

2. Vulnerability: Vulnerability results from different security assumptions between different layers. In a modular blockchain, each module operates independently, introducing potential vulnerabilities. When a specific layer encounters a problem, it may affect other integrated layers—a trade-off inherent in the move toward modularity;

3. Cross-rollup execution: In modular blockchain, cross-rollup execution is crucial to achieve modular blockchain interoperability. The lack of standardized protocols hinders seamless integration between different modules. Additionally, asynchronous execution issues, inherent in sharding, must be addressed to achieve true scalability of modular blockchains;

4. Centralization: Although Rollup’s decentralization may not be as critical as L1’s decentralization, it is still an important security issue. Decentralization is necessary to ensure vitality, resist censorship, and avoid monopolistic advantages. The protocol is actively working on solving these problems through solutions such as shard orderers, abstract boilerplate code, and exposing business logic only to chain developers. Adopting these solutions may help resolve cross-rollup execution issues.

A future of collaboration and inclusion

By examining the above two parts, it is clear that modular and monolithic blockchains represent products of different eras, embody trade-offs in the impossible triangle, and reflect 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, prompting intense zero-sum competition. This environment often leads to extremism as platforms compete for users in their ecosystems.

The emergence of modular blockchain introduces a collaborative and inclusive approach that emphasizes collaboration and interconnection between different chains – a positive development for the entire industry. A collaborative approach allows modules to work seamlessly together, enhancing overall functionality and user experience.

Additionally, the collaborative nature of modular blockchain facilitates the development of innovative and specialized modules. Collaboration and resource sharing between different chains allows developers to focus on specific areas of expertise, resulting in tailor-made, high-quality modules suitable for specific use cases. Additionally, breakouts from the monolithic chain can be decoupled and sequentially merged into modular layers.

It is crucial that modular blockchains and monolithic blockchains are not viewed as adversarial, but rather as complementary. They learn from each other’s strengths and weaknesses and develop together. The boundaries between them may not be obvious, as modular chains can act as middleware for monolithic chains, while monolithic chains can act as specific layers of modular chains.

Rather than focusing on categorical distinctions, the focus should shift to cultivating an open network, embracing key innovations, and building broad consensus.

Appendix:

Introduction to Cross-Consensus Message Format (XCM) · Polkadot Wiki

Polkadot: The Foundation of a New Internet | by Jack Platts | Polkadot Network | Medium

Substrate—Web3 Technology Stack

The OP Stack Landscape | ON Stack Docs

OpenGov: What is Polkadot Gov2 | Moonbeam Network

NEARCON 2023 | Layer 2 Stage—Day 2—YouTube

Ethereum roadmap | ethereum.org

Stateful vs Stateless Architecture: Why Stateless Won | Virtasant

NEAR—The Blockchain Operating | NEAR Documentation

Polygon CDK Implementation Providers

The OP Stack Landscape