Co-exist Future of Smart Contract Platforms

14 min readDec 25, 2023

Author: F.F from LBank Labs Research team

TL; DR

This article serves as a follow-up to our previous research piece, titled “The Opportunities in the Modular Narrative.” In that article, we delved into the modular wave driven by Ethereum and Celestia, and identified various opportunities.

However, it is important to note that the modular narrative should not limit our perspective. Over the past few years, blockchain technology has witnessed significant advancements, with the emergence of both monolithic and modular blockchain architectures.

In this article, we will first analyze these two architectural approaches and compare Ethereum to other Ethereum competitors in the previous cycle. Surprisingly, they share more similarities than one might expect.

Next, we will explore the challenges and specific considerations associated with these two architectural approaches, while also envisioning a future where smart contract platforms coexist. Previously, the blockchain ecosystem was dominated by monolithic blockchains, where each new Layer 1 blockchain operated independently, resulting in fierce competition and limited collaboration. However, we are now at a stage where the connection and interoperability between chains are more developed than ever before. Therefore, our preference would be for open platforms, regardless of whether they are modular or monolithic.

All Architectures Lead to Scaling

This section provides a detailed comparison between Ethereum and other monolithic blockchains, highlighting the differences and similarities in their architectural designs. It discusses the modular design in contrast to monolithic architectures and the challenges associated with achieving true scalability.

While Ethereum itself has adopted a modular design, it also incorporates sharding as a means of achieving scalability. Sharding allows for parallel processing of transactions and data across multiple shards, resulting in increased throughput and capacity. However, the implementation of sharding presents 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 monolithic blockchains. Examples of sharding can be found in Ethereum, Near, and Polkadot.

ETH 2.0 vs Near

Past of Nightshade Design

The comparison between 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 layer and data availability layer are decoupled. This leverages the underlying Layer 1 for security and offers scalability through rollups. In contrast, Near decided to build a sharding network from the beginning, fully considering data sharding and execution sharding in its built-in architecture. This is the first key difference. Ethereum’s rollup-centric approach has a relatively simple design, but it still requires data availability sharding (Danksharding) for layer 2s to work efficiently.

The second key difference is clearly explained below. Near opted for a different sharding solution compared to the common beacon chain and relayer chain. Near itself is divided into different shards, with each shard responsible for chunk generation and storage as part of the block. The so-called “Nightshade” design enables seamless smart contract reads and writes across shards, although it does pose higher barriers for developers. For users, they won’t even recognize the shards they interact with. We discussed the solution to composability and interoperability issues under the modular narrative in the last article. However, this won’t be an issue for Near because its built-in sharding natively allows for cross-shard transactions, similar to cross-rollup transactions in L2s.

The roadmap of Nightshade includes the following phases:

Phase 0: Simple Nightshade with one shard.
Phase 1: Chunk-only producer.
Phase 2: Full Nightshade, where no validators track all shards.
Phase 3: Dynamically adjusting the number of shards based on load.

In terms of progress, Near is currently at the corner between Phase 1 and Phase 2. The Chunk-only producers, introduced last year, can only track the state of one shard. However, there are still full-node validators responsible for maintaining the global state.

Ongoing Starsight: ZK-Centric Sharding

While Near leads the way in sharding design, it has also learned a lot from the Ethereum revolution. To achieve the goal of Phase 2, no validator should track all shards. Instead, the fisherman acts as a security guard, monitoring the state and generating fraud proof in challenges. Its core design is quite similar to optimistic rollup, but implementing it fully is complex. That’s why many protocols are moving away from this solution. For example, Optimism has turned to zk solution, and Arbitrum doesn’t allow permissionless fraud proof submission. Clearly, zkRollups are the future of Ethereum. We can also see the influence of zkRollups in Near’s new sharding design.

Stateless Validation

What if there was a better solution to eliminate the game behind challenges? This is where Near introduces stateless validation. Stateless validation generates a state witness without the need to hand over the state to other shards. With the state witness, there is no longer a need for fisherman or fraud proof.

In the stateless validation setting, there are two types of validators. The former full-node validators are now changed to stateless validators, while the chunk proposer remains the same. Chunk proposers are responsible for producing chunks and state witnesses, and they need to maintain the state of the shard locally. On the other hand, stateless validators receive state witnesses to validate the state transition for each block. With the introduction of validator rotation, it becomes nearly impossible for a validator to corrupt a shard.

Introducing stateless validation brings numerous benefits. The cost of running a stateless validator is much lower than before, allowing more validators to join the consensus. This increases decentralization across the entire network. For chunk proposers, the state of each shard will be much smaller as more shards are added. Since the bottleneck in blockchain is mainly state reads and writes, if the state is held entirely in memory, the performance of a single shard can be dramatically improved.

Magic of Zero-Knowledge Proof

Before the advent of Zero-Knowledge Proof (ZKP), state witnesses were traditionally employed in MPT. However, with the maturity and recent development of ZKP, many protocols, including Near, have readily embraced the transition. ZKP stands out for its ability to offer succinctness and privacy features, significantly reducing the verification cost of state transitions. Apart from its compressed data, ZKP is small and easier to verify. Leveraging recursive proof, the state of all shards can be verified collectively.

The proof of state transition for shards comprises three essential elements: ensuring the correctness of chunk hashes, confirming the accuracy of the state used during execution, and validating the runtime execution. Presently, a challenge persists — the time required for proof generation still exceeds expectations, despite notable improvements over the past year. This situation is expected to evolve further with ongoing enhancements to the proof system and engineering capabilities. That’s the reason why Near made a cooperation with Polygon to co-build zkWASM.

Ce contenu est uniquement pris en charge dans Lark Docs.

To uphold current fast finality without compromising user experience, Near has undergone modular adjustments. Starsight has decoupled consensus and execution, allowing consensus to operate independently, deciding on transactions to be included in a block. Remote Procedure Call (RPC) provides optimistic finality. Once proof generation for a specific state transition is complete, it is committed to a block, and validators subsequently verify the proof’s validity. The proof serves as confirmation for the new state root and the new outgoing receipt root. Zero knowledge proof, in this context, functions similarly to a state witness. However, ZKP can only be confirmed or rejected by consensus, eliminating the need for validator rotation. ZKP, through mathematical assurance of correctness and security, operates much like rollups inheriting the security features of Ethereum.

Ce contenu est uniquement pris en charge dans Lark Docs.

The modular design in a monolithic chain can offer additional benefits. The flexibility of Starsight lies in its applicability not only to the existing Near WASM runtime but also to any runtime where zk proof can be generated for state transitions, such as EVM and Move.

ETH 2.0 vs Polkadot

The Same Design Philosophy

Ethereum 2.0 and Polkadot share more similarities than initially anticipated, a fact underscored by the commonality of their implementation by Gavin Wood. Some have gone so far as to suggest that Polkadot represents the ultimate objective of ETH 2.0. While not entirely accurate, this analogy captures a fundamental truth.

From our perspective, Polkadot exhibits a higher level of maturity in engineering implementation. Without the emergence of Zero-Knowledge (ZK), Ethereum’s rollup-centric architecture aligns closely with Polkadot’s design. A direct terminology comparison reveals striking similarities in their end goals.

Beacon Chain vs Relay Chain
Beacon Chain serves as the coordination layer, emphasizing data availability in a rollup-centric approach.
Relay Chain is responsible for message relaying and maintaining the data of parachains. Shared security is derived from the relay chain. Ethereum positions itself as inheriting security.
Rollup vs Parachain
Parachains are tasked with transaction execution, posting data on the relay chain, and customizing their own state transition.
Rollups execute transactions outside Layer 1, and the data is then posted to Layer 1 where consensus is achieved.

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

Different Strategies and Cycles Lead to Different Outcomes

Despite sharing the same design philosophy and heading towards a common goal, the current state of these two chains is vastly different. According to the stats from Etherscan and Subscan, Ethereum has daily transactions above 1M, while Polkadot has merely 12K in recent days. As for daily active accounts, we have seen 395K on Ethereum and 8k on Polkadot.

The divergence in their current status can be attributed primarily to their respective strategies. Polkadot pursues the realization of the ultimate architecture, intentionally forgoing smart contract capability. Developers are required to build pallets, the appchain module, which poses a significant burden for many. The combination of an aggressive strategy and a high threshold for slot auctions has led to an ecosystem that lacks the vitality needed to offset these challenges.

Conversely, Ethereum prioritizes the market, aiming to cater to market demand. It adjusts its roadmap accordingly, taking a step-by-step approach to progress.

While we won’t delve into the specific reasons behind Ethereum’s thriving and Polkadot’s decline, the comparison between ETH 2.0 and Polkadot offers valuable insights into the future of blockchain architectures and the potential for an open, collaborative ecosystem.

Great Abstraction and Standard

Despite its current challenges, Polkadot boasts numerous advanced designs that are worth exploring and learning from.

The standout contribution from the Polkadot ecosystem is the substate framework, providing a superior abstraction for Appchains. This framework allows project parties to effortlessly initiate their own chains. Beyond the Polkadot ecosystem, we observe a proliferation of active chains built upon Substrate, including projects like Polygon Avail and Starknet Madara, not to mention numerous independent chains.

While pallets may pose a technical burden for smart contract developers, they serve as powerful abstraction tools for protocol developers. These pallets are reusable across all Substrate chains, facilitating community consensus and standardization efforts. This feature allows for specialization and optimization for specific applications. Current trends in Resources as a Service (RaaS), such as OP stack and Polygon CDK, showcase some level of abstraction. However, these initiatives, resembling open-source repositories, are still less comprehensive compared to Substrate. As RaaS matures, we can anticipate greater usability in customization and chain modules.

The second notable feature of Polkadot is the Cross-Consensus Message Passing (XCMP), a message protocol that enables parachains to exchange arbitrary messages without routing through the relay chain. This means that smart contracts can seamlessly call each other within the same parachain and across different parachains.

In contrast, when interacting with different rollups on Ethereum, bridging assets and changing networks are necessary steps. This process introduces challenges such as fragmented liquidity and broken interoperability. To address these issues, we advocate for the Ethereum Foundation to take a leadership role in standard development and actively promote these standards across various rollups. This approach would significantly contribute to a more seamless and interoperable future for Ethereum and its associated ecosystems.

The final significant advancement in Polkadot is the implementation of an on-chain governance module, effectively transforming Polkadot into a true meta-protocol. This module empowers stakeholders to vote directly on-chain, determining the fate of chain upgrades. Once a predefined threshold is reached, the chain autonomously executes the runtime upgrade. This represents a substantial departure from the prevailing social consensus mechanisms in Ethereum today.

Challenges to be Solved

The aforementioned comparison highlights that while there are minor differences, the essence of smart contract platforms remains largely consistent. Thus, certain challenges persist for both monolithic and modular blockchains.

In this section, we will explore two common challenges facing smart contract platforms as a whole before delving into specific concerns related to modular chains.

Key Innovation Dilemma

One of the primary challenges facing smart contract platforms is the need to establish a competitive and innovative environment. The prevalence of EVM-compatible Layer 1 solutions has become somewhat monotonous, with even Vitalik Buterin sorting them based on their compatibility.

While acknowledging the historical significance of the groundbreaking EVM and Solidity, it’s crucial to recognize that technology evolves over time. Sticking to the legitimacy and conventional nature of the EVM may constrain advancements, particularly in the face of Ethereum’s block limit.

The excitement surrounding different architectures, virtual machines (VMs), and smart contract languages stems from a desire to break free from the constraints of the EVM. Embracing diversity in these aspects attracts developers and users who prefer varying programming languages and smart contract functionalities. For instance, in the primary market, Move VM (Aptos, Sui) and Cario VM (Starknet) have garnered high valuations due to the anticipation of bringing innovation and possibilities to the market.

While betting on the next innovative platform, it’s essential to acknowledge the dominance of the EVM’s market share. But as the market matures, it often settles into duopoly pattern, seen in examples like Android & iOS and Windows & Mac.

WASM stands out as a formidable competitor to EVM, with Solana being the largest player. Despite criticisms, Solana’s key innovations, such as the Proof of History (POH) clock, Optimistic Concurrency Control (OCC), and mempool-less transaction forwarding protocol, distinguish it from others and break traditional block design constraints.

In summary, we need to keep an eye on the key innovations in smart contract platforms, whether modular or monolithic, is crucial for pushing the boundaries of blockchain technology.

How to Build Broad Consensus

The consensus we refer to here goes beyond the narrow technical layer and delves into the realm of broad social consensus.

From a consensus perspective, it’s understandable why numerous Layer 1s and Layer 2s opt for EVM compatibility. This choice provides the easiest access to the inflow from the Ethereum ecosystem. However, as the number of EVM chains and rollups increases, the diminishing marginal utility tends to attract transient and disloyal developers and users who may depart swiftly after receiving airdrops.

Beyond EVM compatibility, establishing consensus through restaking presents another compelling narrative to engage an existing community. Building from scratch has become increasingly complex, emphasizing the importance of selecting the right restaking assets. A subtle but crucial point is that assuming all modular layers use Layer 1 Security Derivatives (LSD) to ensure security, the distinction between monolithic blockchains and modular blockchains diminishes.

Moreover, some protocols extend their reach to the broader web2 user base, particularly in the gaming sector. While effective, this approach demands robust business development efforts. Many traditional players prefer expanding their user base as a means to foster consensus in this evolving landscape.

Specific Concerns for Modular Chain

While modular blockchains distribute workloads efficiently across interconnected chains or modules, addressing specific challenges is crucial for achieving true scalability. The key concerns for modular chains include fragmentation, vulnerability, cross-rollup execution, and centralization.

1. Fragmentation: Fragmentation arises from intense competition between different layers. Although current competitors may not immediately cooperate, the evolution of omni protocols and account abstraction is expected to provide users with a seamless experience across products.

2. Vulnerability: Vulnerabilities stem from differing security assumptions among different layers. In a modular blockchain, each module operates independently, introducing potential vulnerabilities. When a specific layer encounters issues, it can affect the other integrated layers — a trade-off inherent in the move towards modularity.

3. Cross-Rollup Execution: Cross-rollup execution is central to achieving interoperability in modular blockchains. The absence of standardized protocols hampers seamless integration between different modules. Additionally, asynchronous execution problems, inherent in sharding, must be addressed for true scalability in modular blockchains.

4. Centralization: While the decentralization of rollups may not be as critical as that of Layer 1s, it remains a crucial security concern. Decentralization is necessary for ensuring liveness, censorship resistance, and avoiding monopolistic advantages. Protocols are actively working to address these concerns through solutions like shard sequencers, abstracting boilerplate code, and exposing only the business logic to chain developers. The adoption of such solutions may contribute to solving cross-rollup execution problems as well.

Cooperative and Inclusive Future

In examining the two sections above, it becomes clear that modular and monolithic blockchains represent products of different eras, embodying trade-offs within the impossible triangle and reflecting different philosophical choices.

For years, the crypto space has been stuck in a monolithic blockchain loop, with each new Layer 1 constructing a closed-off system, fostering fierce and zero-sum competition. This environment often leads to maximalism as platforms vie for users within their ecosystems.

The advent of modular blockchains introduces a cooperative and inclusive approach, emphasizing collaboration and interconnectivity among different chains — a positive development for the entire industry. Cooperative approaches allow modules to seamlessly work together, enhancing overall functionality and user experience.

Moreover, the cooperative nature of modular blockchains promotes innovation and the development of specialized modules. Collaboration and resource-sharing between different chains empower developers to concentrate on specific areas of expertise, resulting in the creation of high-quality modules tailored to specific use cases. Additionally, breakthroughs in monolithic chains can be decoupled and incorporated into modular layers in turn.

It’s crucial to view modular and monolithic approaches not as adversarial but as complementary. They learn from each other’s strengths and weaknesses, developing together. The boundary between them may not be distinct, as modular layers can function as middleware for monolithic chains, and monolithic chains can serve as specific layers for modular chains.

Rather than fixating on categorical distinctions, the focus should shift towards fostering an open network, embracing key innovations, and building broad consensus.

Appendix

Disclaimer: This article is provided for informational purposes only and should not be considered as financial advice. The cryptocurrency market is highly volatile and unpredictable. Always conduct thorough your own research and consult with a qualified financial professional before making any investment decisions.