Cosmos&Polkadot V.S. Layer2 Stacks Chapter 1 Comprehensive Overview of Technical Solutions

Introduction

Recently, various Layer 2 solutions, including Optimism, zkSync, Polygon, Arbitrum, and StarkNet, have been launched, all aiming to build an open-source and modular codebase that allows developers to customize their own Layer 2 solutions, with ETH Layer 2 leading the way.

As we all know, the current Ethereum network is known for its low performance and high gas fees. Although Layer 2 solutions such as OP, zkSync Era have solved these problems, whether deployed on the EVM or Layer 2, they still face a compatibility issue. This not only applies to the underlying code of DApps needing to be compatible with the EVM, but also applies to DApp sovereignty compatibility.

The first part is at the code level. Due to the need for the EVM to accommodate various types of applications deployed on top of it, optimizations have been made for the average user case to cater to all types of users. However, for DApps deployed on top of the EVM, it is not as user-friendly. For example, gamefi applications may prioritize speed and performance, while socialfi users may prioritize privacy and security. But due to the all-encompassing nature of the EVM, DApps must sacrifice certain aspects, resulting in code-level compatibility.

The second part is at the sovereignty level. Since all DApps share the same infrastructure, the concepts of application governance and underlying governance have emerged. Application governance is undoubtedly subject to underlying governance, and specific requirements of certain DApps need to be supported through upgrades to the underlying EVM, resulting in a lack of sovereignty for DApps. For example, the new features of Uniswap V4 require underlying EVM support for Transient Storage, relying on the inclusion of EIP-1153 in the Cancun upgrade.

• CoCreate Web3 needs to reshape the brand, technology only needs to provide a better consumer experience
• Tip Coin releases economic model How many tokens can your points be exchanged for?
• Vitalik’s latest speech Current applications ‘lack imagination’, an independent and open technology stack is the dream of Ethereum.

To address the aforementioned issues of low processing performance and sovereignty on Ethereum L1, Cosmos (2019) and Polkadot (2020) were born. Both aim to help developers build their own customized chains, allowing both blockchain and DApps to have sovereignty and achieve high-performance cross-chain interoperability, creating a fully interconnected network.

Today, four years later, Layer 2 solutions have also launched their own superchain network solutions, from OP Stack, to ZK Stack, then Polygon 2.0, Arbitrum Orbit, and finally StarkNet also joined the trend by introducing the Stack concept.

What kind of collision and spark will there be between the pioneer of the fully interconnected network, CP (Cosmos & Polkadot), and the flourishing Layer 2 solutions? In order to provide a comprehensive and in-depth perspective, we will delve into this topic through a series of three articles. This article, as the first chapter of this series, will provide an overview of the various technical solutions. The second chapter will analyze the economic models and ecosystems of each solution, and summarize the characteristics to consider when choosing between Layer 1 and Layer 2 Stack. In the final chapter, we will explore how Layer 2 can develop its own superchain and summarize the entire series of articles.

I. Cosmos

Cosmos is a decentralized network of independent parallel blockchains. By providing a universal development framework SDK, developers can easily build their own blockchains. Multiple independent and different application-specific blockchains can be linked and communicate with each other, forming an interoperable and scalable fully interconnected network.

1. Structure Framework

As mentioned earlier, when there are large-scale application chains in the ecosystem, and each chain communicates and transfers tokens using the IBC protocol, the overall network becomes as complicated and difficult to understand as a spider’s web.

To solve this problem, Cosmos proposes a layered architecture that includes two types of blockchains: Hubs and Zones.

Zones are regular application chains, and Hubs are blockchains specifically designed to connect Zones together, primarily serving communication between Zones. When a Zone establishes an IBC connection with a Hub, the Hub can automatically access (i.e., send and receive) all the Zones connected to it. This structure greatly reduces communication complexity.

It is also important to note that Cosmos and Cosmos Hub are two completely different things. Cosmos Hub is just one of the chains within the Cosmos ecosystem, primarily serving as the issuer and communication center for $ATOM. You may think of the Hub as the center of the ecosystem, but in fact, any chain can become a Hub. If the Hub becomes the center of the ecosystem, it actually goes against the original intention of Cosmos. Because Cosmos is essentially committed to the autonomy of each chain, with absolute sovereignty. If the Hub becomes the center of power, sovereignty is no longer sovereignty. Therefore, when understanding the Hub, it is important to pay special attention to this point.

2. Key Technologies

2.1 IBC

IBC (Inter-Blockchain Communication) allows for the transfer of tokens and data between heterogeneous chains. In the Cosmos ecosystem, the SDK underlying framework is the same and must use the Tendermint consensus engine. However, heterogeneity still exists because chains within the framework may have different functionalities, use cases, and implementation details.

So how can communication between chains with heterogeneous properties be achieved?

It only requires consensus-level finality. Finality refers to the fact that as long as more than 1/3 of the validators are correct and determined, the block will not fork, ensuring that once a transaction is included in a block, it is final. Regardless of the differences in application cases and consensus among heterogeneous chains, as long as their consensus levels satisfy finality, there are unified rules for interoperability between chains.

The following is a basic process for cross-chain communication, assuming that 10 $ATOM needs to be transferred from Chain A to Chain B:

1. Tracing: Each chain runs a light node of other chains, so each chain can verify other chains.

2. Bonding: Lock the 10 $ATOM on Chain A and send the lock proof.

3. Relay: There is a relay between Chain A and Chain B to send the lock proof.

4. Validation: Verify the blocks of Chain A on Chain B. If they are correct, 10 $ATOM will be created on Chain B.

At this time, the $ATOM on chain B is not the real $ATOM, it is just a voucher. The locked $ATOM on chain A cannot be used, but the $ATOM on chain B can be used normally. When the user consumes the voucher on chain B, the locked $ATOM on chain A will also be destroyed.

However, the biggest challenge faced by cross-chain communication is not how to represent the data on one chain on another, but how to handle situations like chain forks and chain reorganizations.

Because each chain in Cosmos is an independent and autonomous individual chain with its own dedicated validators, it is very likely that there will be malicious behavior in the partition. For example, if chain A transmits a message to chain B, it is necessary to verify the validators of chain B in advance before deciding whether to trust that chain.

For example, suppose the small red dots in the picture represent a token called ETM, and users in the ABC partitions all want to use EVMOS to run Dapps in their respective partitions. Through cross-chain communication, they have all received ETM.

If Ethermint launches a double-spending attack at this time, the ABC partitions will undoubtedly be affected, but it is limited to this. The remaining network unrelated to ETM will not receive any attacks. This is also guaranteed by Cosmos, that even if such malicious information transmission occurs, it still cannot affect the entire network.

2.2 Tendermint BFT

Cosmos adopts Tendermint BFT as the underlying consensus algorithm and consensus engine for Cosmos. It combines the underlying infrastructure and consensus layer of the blockchain into a universal engine solution, and uses ABCI technology to support encapsulation of any programming language, thereby adapting to the underlying consensus layer and network. Therefore, developers can freely choose any language they like.

2.3 Cosmos SDK

Cosmos SDK is a modular framework launched by Cosmos, which simplifies the operation of building Dapps on the consensus layer. Developers can easily create specific applications/chains without having to rewrite the code for each module, greatly reducing development pressure. It is now also allowed for developers to port applications deployed on EVM to Cosmos.

Source:https://v1.cosmos.network/intro

In addition, blockchain built using Tendermint and Cosmos SDK are also leading the industry in terms of new ecology and new technologies, such as privacy chain Nym, data availability provider Celestia, and so on. It is precisely because of the flexibility and ease of use provided by Cosmos that developers can focus on project innovation without having to consider repetitive work.

2.4 Interchain Security & Account

1) Interchain Security

Because Cosmos is different from the Ethereum ecosystem, which has L1 and L2, each application chain in the Cosmos ecosystem is equal to each other and there is no hierarchical relationship. However, due to this reason, interchain security is not as perfect as Ethereum. In Ethereum, the final determinism of all transactions is confirmed by Ethereum, inheriting the underlying security. But for a self-built monolithic blockchain, how should security be maintained?

Cosmos has introduced Interchain Security, which essentially achieves shared security by sharing a large number of existing nodes. For example, a single chain can share a set of validation nodes with Cosmos Hub to generate new blocks for the single chain. Since the nodes serve both Cosmos Hub and the single chain, they can receive fees and rewards from both chains.

Source:https://medium.com/tokenomics-dao/token-use-cases-LianGuairt-1-atom-a-true-staking-token-5fd21d41161e

As shown in the figure, the transactions generated internally by chain X are generated and verified by X’s nodes to create blocks. If they share nodes with Cosmos Hub ($ATOM), the transactions generated on chain X will be verified and calculated by the nodes of the Hub chain, generating new blocks for X.

In theory, choosing a chain with a large number of nodes and a more mature chain like Hub is the preferred option for shared security. Because if you want to attack such a chain, attackers need to have a large amount of $ATOM tokens for staking, increasing the difficulty of the attack.

Furthermore, the Interchain Security mechanism greatly reduces the barriers to creating new chains. Generally speaking, a new chain may need to spend a lot of time attracting validators and cultivating the ecosystem if it does not have particularly outstanding resources. However, in Cosmos, because it can share validators with the Hub chain, it greatly alleviates the pressure on new chains and accelerates the development process.

2) Interchain Account

In the Cosmos ecosystem, because each application chain governs itself, applications cannot access each other. Therefore, Cosmos provides a cross-chain account that allows users to directly access all Cosmos chains that support IBC from Cosmos Hub, allowing users to access applications on Chain B from Chain A, achieving full chain interaction.

II. Polkadot

Like Cosmos, Polkadot is committed to building an infrastructure that allows for the free deployment of new chains and interoperability between chains.

1. Structural Framework

1.1 Relay Chain:

The relay chain, also known as the main chain, can be understood as the sun in the solar system, which is the core part of the entire network, and all the parachains revolve around it. As shown in the figure, a relay chain is connected to many different chains, such as transaction chains, file storage chains, IoT chains, and so on.

Source:https://medium.com/polkadot-network/polkadot-the-foundation-of-a-new-internet-e8800ec81c7

This is Polkadot’s layered expansion plan, where one relay chain is connected to another relay chain, achieving unlimited scalability. (Note: At the end of June this year, Polkadot founder Gavin proposed Polkadot 2.0, which may change the way we understand Polkadot.)

1.2 Parachains:

The relay chain has several parachain slots, and parachains are connected to the relay chain through these slots, as shown in the figure:

Source:https://www.okx.com/cn/learn/slot-auction-cn

However, to obtain a slot, the parallel chain must stake their $DOT. Once the slot is obtained, the parallel chain can interact with the Polkadot mainnet through this slot and share security. It is worth mentioning that the number of slots is limited and will gradually increase. It is initially expected to support 100 slots, and the slots will be periodically reshuffled and allocated according to the governance mechanism to maintain the vitality of the parallel chain ecosystem.

The parallel chain that obtains the slot can enjoy the shared security and cross-chain liquidity of the Polkadot ecosystem. At the same time, the parallel chain also needs to provide certain returns and contributions to the Polkadot mainnet as a reward, such as taking on most of the network’s transaction processing.

1.3 Parallel Threads:

Parallel threads are another processing mechanism similar to parallel chains, but the difference is that parallel chains have dedicated slots, which can run continuously. However, parallel threads refer to sharing slots between parallel threads and taking turns to use this slot for operation.

When a parallel thread obtains the right to use the slot, it can temporarily work like a parallel chain, processing transactions, generating blocks, etc. However, when this time period ends, the slot must be released for other parallel threads to use.

Therefore, parallel threads do not need to stake assets for a long time, they only need to pay a certain fee when obtaining each time period, so it can be said to be a pay-as-you-go method to use the slot. Of course, if a parallel thread receives enough support and votes, it can be upgraded to a parallel chain and obtain a fixed slot.

Compared to parallel chains, parallel threads have lower costs, reducing the entry barrier for Polkadot. However, it cannot guarantee when it can obtain the right to use the slot, so it is less stable. Therefore, it is more suitable for temporary use or testing of new chains. Those chains that hope to operate stably still need to upgrade to parallel chains.

1.4 Bridge:

The communication between parallel chains can be achieved through XCMP (as mentioned later), and they share security and have the same consensus. But what about heterogeneous chains?

It should be noted here that although the framework provided by Substrate makes it possible for chains that access the Polkadot ecosystem to be homogenous, as the ecosystem develops, there will inevitably be some well-established and large-scale public chains that want to participate in the ecosystem. It is almost impossible for them to redeploy using only Substrate. So how to achieve message transmission between heterogeneous chains?

Using an example from daily life, if an iPhone wants to transfer files to an Android phone through a connection, a converter is needed to connect the different ports. This is the actual role of the bridge. It is a parallel chain that serves as an intermediary between the relay chain and the heterogeneous chain (external chain). Smart contracts are deployed on the parallel chain and the heterogeneous chain, allowing the relay chain to interact with the external chain and achieve cross-chain functionality.

2. Key Technologies

2.1 BABE&GrandLianGuai

BABE (Blind Assignment for Blockchain Extension) is the block production mechanism of Polkadot. Simply put, it randomly selects validators to produce new blocks, and each validator is assigned to a different time slot. Only the validator assigned to a specific time slot can produce a block within that time slot.

Additional Explanation:

• A time slot is a method used in the block production mechanism of a blockchain to divide the time sequence. The blockchain is divided into time slots that appear at fixed intervals. Each time slot represents a fixed block production time.

• Within each time slot interval, only the nodes assigned to that time slot can produce blocks.

In other words, it is an exclusive time period. In time slot 1, validator 1 assigned to this time slot is responsible for block production. Each validator has a unique time slot and cannot produce blocks repeatedly.

The advantage of this approach is that random assignment maximizes fairness, as everyone has a chance to be assigned. And because the time slots are known, everyone can prepare in advance, avoiding unexpected block production.

Through this randomly assigned block production method, the orderly and fair operation of the Polkadot ecosystem is ensured. But how can the blocks adopt the same consensus? Next, we will introduce another mechanism of Polkadot: GrandLianGuai.

GrandLianGuai is a mechanism for determining the final blocks. It can solve the problem of forks that may occur during BABE block production due to different consensus. For example, if BABE node 1 and node 2 produce different blocks in the same time slot, a fork occurs. At this time, GrandLianGuai comes into play and asks all validators: which chain do you think is better?

The validators will review the two chains and vote for the one they believe is better. The chain with the most votes will be confirmed as the final chain by GrandLianGuai, while the rejected chain will be discarded.

So GrandLianGuai acts like the “grandfather” of all validators, playing the role of the ultimate decision maker, eliminating the fork risk that BABE may bring. It allows the blockchain to ultimately determine a chain that is accepted by everyone.

In summary, BABE is responsible for randomly producing blocks, and GrandLianGuai is responsible for selecting the final chain. Together, they enable the safe operation of the Polkadot ecosystem.

2.2 Substrate

Substrate is a framework written in the Rust programming language that provides underlying scalable components provided by FRAME. This allows Substrate to support the development of various use cases. Any blockchain built using Substrate is not only compatible with Polkadot natively, enabling sharing of security and parallel execution with other parachains, but also supports developers to build their own consensus mechanisms, governance models, etc., according to their needs.

In addition, Substrate provides great convenience for self-upgrade because it is an independent module at runtime and can be separated from other components. Therefore, when updating functionality, you can directly replace the running module. As a shared consensus parallel chain, as long as it maintains network and consensus synchronization with the relay chain, it can update the running logic directly without a hard fork.

2.3 XCM

If XCM is explained in one sentence, it is: a cross-chain communication format that allows different blockchains to interact with each other.

For example, Polkadot has many parallel chains. If parallel chain A wants to communicate with parallel chain B, it needs to package the information using the XCM format. XCM is like a language protocol that everyone uses to communicate, enabling seamless communication.

XCM format (Cross-Consensus Message Format) is the standard message format used for cross-chain communication in the Polkadot ecosystem, and it has derived three different message delivery methods:

• XCMP (Cross-Chain Message Passing): Under development. Messages can be directly transmitted or relayed through the relay chain. Direct transmission is faster, while relayed transmission is more scalable but introduces latency.

• HRMP/XCMP-lite (Horizontal Relay Message Passing): In use. It is a simplified version of XCMP and serves as the main solution for cross-chain message passing by storing all messages on the relay chain.

• VMP (Vertical Message Passing): Under development. It is a protocol for vertically passing messages between the relay chain and parallel chains. Messages are stored on the relay chain and then passed on after being parsed by the relay chain.

For example, since the XCM format contains various information such as the amount of assets to transfer and the receiving account, when sending a message, the HRMP channel or the relay chain will transmit this XCM format message. The receiving parallel chain will check if the format is correct, parse the message content, and then execute the instructions in the message, such as transferring assets to the specified account. This achieves cross-chain interaction, and the two chains successfully communicate with each other.

Communication bridges like XCM are crucial for multi-chain ecosystems like Polkadot.

After understanding Cosmos and Polkadot, I believe you have a grasp of their visions and frameworks. Next, we will explain in detail what the Stack solutions introduced by ETH L2s are.

III. OP Stack

1. Structural Framework

According to the official documentation, OP Stack is a series of components maintained by OP Collective. It first appears as software behind the mainnet and eventually appears in the form of the Optimism superchain and its governance. L2 developed using OP Stack can share security, communication layer, and general development stack. Moreover, developers can customize chains freely to serve specific blockchain use cases.

From the diagram, we can understand that all superchains of OP Stack communicate through the OP Bridge superchain bridge and rely on Ethereum as the underlying security consensus to build super L2 chains. The internal structure of each superchain is divided into:

1) Data Availability Layer: Chains that use the OP Stack can use this data availability module to retrieve their input data. Because all chains get their data from this layer, it has a significant impact on security. If a certain piece of data cannot be retrieved from this layer, it may not be possible to synchronize the chain.

From the diagram, we can see that OP Stack uses Ethereum and EIP-4844, which essentially means accessing data on the Ethereum blockchain.

2) Sequencing Layer: The Sequencer determines how user transactions are collected and published to the data availability layer. In the OP Stack, a single dedicated sequencer is used for processing. However, this may result in the sequencer not being able to retain transactions for too long. In the future, OP Stack will modularize the sequencer module to allow chains to easily change their sequencing mechanism.

In the diagram, we can see a single sequencer and multiple sequencers. A single sequencer allows any entity to act as a Sequencer at any time (higher risk), while multiple sequencers are selected from a predefined set of potential participants. If multiple sequencers are chosen, each chain developed based on OP Stack can make a specific selection.

3) Derivation Layer: This layer determines how the raw data of data availability is processed and transmitted to the execution layer through Ethereum’s API. From the image, we can see that OP Stack consists of Rollup and Indexer.

4) Execution Layer: This layer defines the state structure within the OP Stack system. When the engine API receives input from the derivation layer, it triggers state transitions. From the diagram, we can see that within OP Stack, the execution layer is the EVM. However, with slight modifications, it can also support other types of VMs. For example, Pontem Network plans to develop an L2 with a Move VM using OP Stack.

5) Settlement Layer: As the name suggests, it is used to handle the extraction of assets from the blockchain. However, such withdrawals require proving the state of the target chain to a certain third-party chain and processing the assets based on the state. The key is to allow the third-party chain to understand the state of the target chain.

Once a transaction is published on the corresponding data availability layer and finally confirmed, the transaction is also finally confirmed on the OP Stack chain. It cannot be modified or deleted without breaking the underlying data availability layer. The transaction may not have been accepted by the settlement layer yet because the settlement layer needs to be able to verify the transaction result, but the transaction itself is immutable.

At the same time, this is also a mechanism for heterogeneous chains. The settlement mechanism of heterogeneous chains varies, so in OP Stack, the settlement layer is read-only, allowing heterogeneous chains to make decisions based on the state of OP Stack.

In this layer, we can see that OP Stack uses fraud proofs in OP Rollup. Proponents can present valid states that they question. If they are not proven wrong within a certain period of time, they will be automatically considered correct.

6) Governance Layer: From the diagram, we can see that OP Stack uses multi-signature + $OP token for governance. Multi-signature is typically used for managing upgrades to Stack system components, and operations are executed when participants have all signed. $OP token holders can vote to participate in governance of the community DAO.

OP Stack is like a combination of Cosmos and Polkadot, it can customize exclusive chains like Cosmos, and also share security and consensus like Polkadot.

2. Key Technologies

2.1 OP Rollup

OP Rollup ensures security through data availability challenges, allowing parallel execution of transactions. The specific implementation steps are as follows:

1) Users initiate transactions on L2.

2) Sequencer will batch process and synchronize the processed transaction data and new state root to the smart contract deployed on L1 for security verification. It is worth noting that the Sequencer will generate its own state root while processing transactions, which will also be synchronized to L1.

3) After verification, L1 returns the data and state root to L2, and the user’s transaction status is securely verified and processed.

4) At this point, OP Rollup considers the state root generated by the Sequencer as optimistic and correct. It opens a time window for validators to challenge whether the state root generated by the Sequencer matches the transaction’s state root.

5) If no validators verify during the time window, the transaction will be automatically considered correct. If malicious fraud is detected, the Sequencer handling the transaction will be punished accordingly.

2.2 Cross-Chain Bridging

a) Intra-L2 message passing

Due to the use of fraud proofs in OP Rollup, transactions need to wait for challenges to complete, which is time-consuming and has a lower user experience. However, ZKP (Zero-Knowledge Proof) is costly and error-prone, and it also takes time to implement batch ZKP.

To solve the communication problem between L2 OP chains, OP Stack proposes modular proofs: using two proof systems for the same chain, developers building L2 Stacks can freely choose any bridging type.

Currently, OP provides:

1. High security, high latency fault tolerance (standard high-security bridge)

2. Low security, low latency fault tolerance (short challenge period for low latency)

3. Low security, low latency correctness proof (using trusted chain provers instead of ZKP)

4. High security, low latency correctness proof (after ZKP is ready)

Developers can choose bridging focuses according to the needs of their own chains, such as selecting a high-security bridge for high-value assets… Diverse bridging technologies allow efficient movement of assets and data between different chains.

b) Cross-Chain Transactions

Traditional cross-chain transactions are completed asynchronously, which means that transactions may not be fully executed.

OP Stack addresses this issue by proposing the concept of shared sequencers. For example, if a user wants to execute cross-chain arbitrage, A chain and B chain can share a sequencer, reaching a consensus on the timing of transactions. The fee will only be paid after the transactions are confirmed on both sides, and both sequencers share the risk.

c) Cross-chain Transactions

Because the scalability of Ethereum L1’s data availability is not sufficient (limited capacity), it is not scalable to publish transactions to the superchain.

Therefore, in the OP Stack, the use of the Plasma protocol to expand the amount of data accessible by the OP chain is proposed, which can supplement more L1 data instead of DA (data availability). Moving the transaction data availability to the Plasma chain and only recording data commitments on L1 greatly improves scalability.

IV. ZK Stack

1. Structural Framework

ZK Stack is an open-source, composable, and modular code built with the same underlying technology (ZK Rollup) as zkSync Era, allowing developers to customize their own ZK-driven L2 and L3 superchains.

Since ZK Stack is free and open-source, developers can freely customize superchains according to their specific needs. Whether it is choosing a second-layer network that runs in parallel with zkSync Era or a third-layer network running on top of it, the possibilities for customization will be extensive.

According to Matter Labs, creators have complete autonomy to customize and shape various aspects of the chain, from choosing data availability modes to using their own project’s token as a decentralized sorter.

Of course, these ZK Rollup superchains run independently but rely on Ethereum L1 for security and verification.

Source: zkSync Document

From the chart, it can be seen that each superchain must use the zkEVM engine of zkSync L2 to share security. Multiple ZKP chains run concurrently and aggregate block proofs at the settlement layer of L1, allowing for continuous expansion and the construction of more L3, L4…

2. Key Technologies

1) ZK Rollup

ZK Stack is built on the ZK Rollup as its core technology. The main user process is as follows:

Users submit their transactions, and the Sequencer combines the transactions into ordered batches and generates validity proofs (STARK/SNARK) for state updates. The updated state is then submitted to the smart contract deployed on L1 for verification. If the verification is successful, the asset state on the L1 layer will also be updated. The advantage of ZK Rollup is its ability to mathematically verify through zero-knowledge proofs, making it higher in technology and security.

2) Interchain Bridge

In the structural framework mentioned above, ZK Stack can achieve infinite scalability by continuously generating L3, L4, and so on. So how to achieve interoperability between superchains?

ZK Stack introduces an interchain bridge, which verifies the transactions occurring on the superchain through Merkle proofs by deploying a shared bridge smart contract on L1. Essentially, it is consistent with ZK Rollup, except that it transitions from L2-L1 to L3-L2.

ZK Stack supports smart contracts on various chains, allowing for cross-chain asynchronous invocation. Users can transfer their assets quickly and without trust in just a few minutes, without incurring any additional costs. For example, in order to process a message on chain B, chain A must always finalize its state until the earliest chain that serves as the common foundation for both A and B. Therefore, in practice, the communication delay of the cross-bridge is only a matter of a few seconds, and the chain can complete blocks every second and at a lower cost.

Source:https://era.zksync.io/docs/reference/concepts/hyperscaling.html#l3s

What’s more, since L3 can utilize compression technology, proofs can be packed. L2 will further expand the packing, resulting in a more significant compression ratio and lower costs (recursive compression), enabling trustless, fast (within minutes), and cheap (single transaction cost) cross-chain interoperability.

五. Polygon 2.0

Polygon is a special L2 solution, technically an L1, acting as a sidechain of Ethereum. The Polygon team recently announced the Polygon 2.0 plan, which allows developers to create their own ZK L2 chains using ZK support and unify them through a novel cross-chain coordination protocol, making the entire network feel like using a single chain.

Polygon 2.0 aims to support an unlimited number of chains, and cross-chain interactions can occur securely and instantly without additional security or trust assumptions, achieving unlimited scalability and unified liquidity.

1. Structure

Source: Polygon Blog

Polygon 2.0 consists of four protocol layers:

1) Staking Layer

The Staking Layer is a PoS-based protocol that utilizes staked $MATIC for decentralized governance, efficient validator management, and improved miner efficiency.

As shown in the diagram, the Staking Layer in Polygon 2.0 introduces a Validator Manager and a Chain Manager.

1. Validator Manager: It manages a shared pool of validators for all Polygon 2.0 chains. This includes validator registration, staking requests, unstaking requests, etc. It can be seen as the administrative department for validators.

2. Chain Manager: It manages the set of validators for each Polygon 2.0 chain. Unlike the Validator Manager, which is a public service, each Polygon chain has its own Chain Manager contract. The Chain Manager focuses more on the validation management of each corresponding chain, such as the number of validators (which determines the level of decentralization), additional requirements for validators, and other conditions.

The Staking Layer has established the underlying architecture with corresponding rules for each chain, allowing developers to focus on developing their own chains.

Source: Polygon Blog

2) Interoperability Layer

Interoperability protocols are crucial for the connectivity of the entire network. How to securely and seamlessly transmit cross-chain messages is something that every blockchain solution should continuously improve.

Currently, Polygon uses two types of contracts to support interoperability: Aggregator and Message Queue.

1. Message Queue: It has been modified and upgraded for the existing Polygon zkEVM protocol. Each Polygon chain maintains its local message queue in a fixed format, and these messages are included in the ZK proofs generated by that chain. Once the ZK proof is verified on Ethereum, any messages from that queue can be safely used by the receiving chain and address.

2. Aggregator: The existence of the aggregator aims to provide more efficient services between Polygon chains and Ethereum. For example, aggregating multiple ZK proofs into one and submitting it to Ethereum for verification to reduce storage costs and improve performance.

Once the ZK proof is accepted by the aggregator, the receiving chain can start optimistically accepting messages because the receiving chain trusts the ZK proof, achieving seamless message transmission and so on.

3) Execution Layer

The execution layer allows any Polygon chain to generate batches of ordered transactions, also known as blocks. Most blockchain networks (such as Ethereum, Bitcoin, etc.) use a similar format for it.

The execution layer has multiple components, such as:

1. Consensus: Allows validators to reach consensus.

2. Mempool: Collects transactions submitted by users and synchronizes them among validators. Users can also check the status of their transactions in the mempool.

3. P2P: Allows validators and full nodes to discover each other and exchange messages.

4. …

Since this layer has been commoditized, but implementation is relatively complex, existing high-performance implementations (such as Erigon) should be reused as much as possible.

4) Proof Layer

The proof layer generates proofs for each Polygon chain. It is a high-performance and flexible ZK proof protocol, usually consisting of the following components:

1. Common Prover: A high-performance ZK prover that provides a clean interface intended to support any transaction type, i.e., state machine format.

2. State Machine Constructor: A framework for defining the state machine, used to build the initial Polygon zkEVM. This framework abstracts the complexity of the proof mechanism and simplifies it into an easy-to-use, modular interface, allowing developers to customize parameters and build their own large-scale state machines.

3. State Machine: A simulation of the execution environment and transaction format that the prover is proving. The state machine can be implemented using the aforementioned constructor or fully customized, such as using Rust.

2. Key Technologies

Source: Polygon Blog

1) zkEVM validium

In the Polygon 2.0 update, the team kept the original Polygon POS and upgraded it to zkEVM validium.

Source: Polygon Blog

Here’s a simple explanation: Validium and Rollup are both Layer 2 solutions designed to increase Ethereum’s transaction capacity and reduce transaction time. Compared to each other:

• Rollup bundles many transactions together and submits them as a batch to the Ethereum main chain, utilizing Ethereum to publish transaction data and verify proofs, thus inheriting its unparalleled security and decentralization. However, publishing transaction data to Ethereum is costly and limits throughput.

• Validium does not require submitting all transaction data to the main chain. It uses zero-knowledge proofs (ZKPs) to prove the validity of transactions, with the transaction data provided off-chain. It also protects user privacy. However, Validium relies on a trusted execution environment and is relatively more centralized.

Validium can be understood as a lower-cost and more scalable version of Rollup. However, the previous version of Polygon zkEVM (Polygon POS mechanism) before the upgrade operated as (ZK) Rollup and achieved remarkable results. Within just 4 months of its launch, its TVL (Total Value Locked) had already skyrocketed to $33 million.

Source: Defilama

In the long run, the cost of generating proofs for zkEVM based on Polygon POS may become a hindrance to future scalability. Although the Polygon team has been committed to reducing batch costs, the cost has already been reduced to an extremely impressive figure: it costs only $0.0259 to prove 10 million transactions. However, why not use Validium, which has even lower costs?

Polygon has already released documentation stating that in future versions, Validium will take on the previous role of POS while still retaining POS. The main role of POS validators will be to ensure data availability and order transactions.

The upgraded zkEVM Validium will provide high scalability and low costs. It is particularly suitable for applications with high transaction volume and low transaction fees, such as Gamefi, Socialfi, and DeFi, among others. For developers, no additional operations are required. Simply update along with the mainnet to complete the Validium update.

2) zkEVM rollup

Currently, Polygon POS (soon to be upgraded to Polygon Validium) and Polygon zkEVM Rollup are the two public networks in the Polygon ecosystem. After the upgrade, both networks will continue to use cutting-edge zkEVM technology, one for aggregation and the other for verification, bringing additional benefits.

Polygon zkEVM Rollup already provides the highest level of security, but at the cost of slightly higher fees and limited throughput. However, it is ideal for applications that handle high-value transactions and prioritize security, such as high-value DeFi Dapps.

Six. Arbitrum Orbit

Arbitrum, as the current main L2 public chain, has had a TVL of over $5.1 billion since its launch in August 2021, occupying nearly 54% of the market share as a leading L2.

In March of this year, Arbitrum released the Orbit version, and prior to that, Arbitrum had issued a series of ecosystem products:

1. Arbitrum One: The first and core mainnet Rollup of the Arbitrum ecosystem.

2. Arbitrum Nova: The second mainnet Rollup of Arbitrum, targeting projects that are cost-sensitive and have high transaction volume requirements.

3. Arbitrum Nitro: A technical software stack that supports Arbitrum L2, enabling Rollups to be faster, cheaper, and more compatible with EVM.

4. Arbitrum Orbit: A development framework for creating and deploying L3 on the Arbitrum mainnet.

Today, we will focus on Arbitrum Orbit.

1. Structural Framework

Originally, if developers wanted to use Arbitrum Orbit to create an L2 network, they would first propose it and have the Arbitrum DAO vote on it. If approved, a new L2 chain would be created. However, there is no need for permission to develop L3, L4, L5, etc. on L2. Anyone can provide a permissionless framework for deploying customized chains on Arbitrum L2.

Source: WhiteLianGuaiper

As you can see, Arbitrum Orbit also aims to allow developers to customize their own Oribit L3 chains through Layer 2-based solutions such as Arbitrum One, Arbitrum Nova, or Arbitrum Goerli. Developers can customize the chain’s privacy protocols, licenses, token economic models, community management, and more, giving them maximum autonomy.

One notable feature is that Oribit allows L3 chains to use the native token of the chain as the unit of fee settlement, effectively developing their own network.

2. Key Technologies

1) Rollup & AnyTrust

These two protocols respectively support Arbitrum One and Arbitrum Nova. As previously mentioned, Arbitrum One is a core mainnet Rollup, while Arbitrum Nova is the second mainnet Rollup that incorporates the AnyTrust protocol, which can accelerate settlement and reduce costs by introducing a “trust assumption.”

Arbitrum Rollup is an OP Rollup, so we won’t go into too much detail. We will focus on the AnyTrust protocol.

The AnyTrust protocol primarily manages data availability and is overseen by a series of third-party institutions such as the Data Availability Committee (DAC). It greatly reduces transaction costs by introducing a “trust assumption.” The AnyTrust chain operates on Arbitrum One as a sidechain, with lower costs and faster transaction speeds.

So, what exactly is the “trust assumption” and why does its existence reduce transaction costs and require lower trust?

According to Arbitrum’s official documentation, the AnyTrust chain is operated by a committee of nodes, and the minimum assumption is made to determine how many committee members are honest. For example, if the committee consists of 20 people, it is assumed that at least 2 members are honest. Compared to BFT, which requires 2/3 of members to be honest, AnyTrust does indeed lower the threshold of trust.

In a transaction, because the committee promises to provide transaction data, the nodes do not need to record all the data of L2 transactions on L1, but only need to record the hash value of the transaction batch. This greatly saves the cost of Rollup. This is also why the AnyTrust chain can reduce transaction costs.

Regarding trust issues, as mentioned earlier, assuming that as long as 2 out of 20 members are honest and the assumption holds. As long as 19 members of the committee sign the commitment to the correctness of this transaction, it can be safely executed. So even if the member who is not signed is honest, there must be at least 1 honest member among the 19 who have signed.

What if members do not sign or a significant number of members refuse to cooperate, resulting in the inability to run normally? The AnyTrust chain can still run, but it will revert to the original Rollup protocol and the data will still be published on the Ethereum L1. When the committee runs normally, the chain will switch back to a cheaper and faster mode.

The reason why Aribtrum launched this protocol is to meet the needs of applications that require high processing speed and low cost, such as the Gamefi field.

2) Nitro

Nitro is the latest version of Arbitrum technology, and its main element is the validator (Prover), which uses WASM code to perform traditional interactive fraud proofs on Arbitrum. And all its components are complete. Arbitrum has completed the upgrade at the end of August 22, seamlessly migrating/upgrading the existing Arbitrum One to Aribitrum Nitro.

Nitro has the following characteristics:

• Two-stage transaction processing: Users’ transactions are first integrated into a single ordered sequence, and then Nitro submits this sequence to process transactions in order and achieve deterministic state transitions.

• Geth: Nitro uses the most widely supported Ethereum client Geth (go-ethereum) to support Ethereum’s data structure, format, and virtual machine, which can better be compatible with Ethereum.

• Separate execution and proof: Nitro compiles the same source code twice, once as native code to execute transactions in Nitro nodes, and again as WASM for proof.

• OP Rollup with interactive fraud proofs: Nitro uses OP Rollup, including Arbitrum’s original interactive fraud proofs, to settle transactions on the first layer of the Ethereum chain.

These features of Oribit provide technical support for Arbitrum’s L3, L4 use cases, and Arbitrum can attract developers seeking customization to create their own custom chains.

7. Starknet Stack

Eli Ben-Sasson, co-founder of StarkWare, announced at the EthCC conference in Paris that Starknet is about to launch the Starknet Stack, allowing any application to deploy its own Starknet application chain in a permissionless manner.

The key technologies in Starknet, such as STARK proofs, the Cairo programming language, and native account abstraction, provide the driving force for the rapid development of Starknet. When developers use the Stack to customize their own Starknet application chains, it can be scalable, freely configurable, greatly expand network throughput, and alleviate congestion on the mainnet.

Although Starknet is currently only a preliminary concept and has not yet released official technical documentation, the Madara Sequencer and LambdaClass are developing Starknet-compatible Sequencer and Stack components respectively to better adapt to Starknet. The official team is also making efforts for the upcoming Starknet Stack, including the development of components such as full nodes, execution engines, and validators.

It is worth noting that StarkNet recently submitted a proposal for a “Simple Decentralized Protocol” in hopes of changing the current situation where L2s are operated by a single Sequencer. Ethereum is decentralized, but L2s are not, and their MEV revenue makes the Sequencer corrupt.

In the proposal, StarkNet lists some solutions, such as:

1. L1 Staking and Leader Election: Community members can join the Staker pool on Ethereum without permission to become a Staker. Based on the distribution of assets in the pool and a random number on L1, a group of Stakers is randomly selected as Leaders responsible for block production in an Epoch. This not only lowers the threshold for Staker users but also effectively prevents gray MEV revenue through randomness.
2. L2 Consensus Mechanism: Based on Tendermint, the Byzantine Fault Tolerant consensus mechanism in which Leaders participate as nodes. After consensus confirmation, execution is performed by Voters, and Provers are invoked by Proposers to generate ZKPs.

In addition, there are solutions involving ZK proofs, L1 state updates, and other measures. Combined with the previous major step of supporting community-operated Prover code without permission, StarkNet’s proposal aims to address the lack of decentralization in L2 and attempts to balance the blockchain scalability trilemma, which is commendable.

Source: https://starkware.co/resource/the-starknet-stacks-growth-spurt/

8. Conclusion

In this chapter, by explaining the technology of CP and various Layer 2 Stacks, we can see that the current Layer 2 Stack solutions can effectively solve Ethereum’s scalability problem, but they also bring a series of challenges and issues, especially in terms of compatibility. The technology in L2 Stack solutions is not as mature as CP, and even the technology ideas from three or four years ago are still worth learning from for current L2s. Therefore, at the technical level, CP is still far ahead of Layer 2. However, having advanced technology alone is not enough. In the next article, we will discuss the value of tokens and the development of the ecosystem, comparing and analyzing the advantages, disadvantages, and characteristics of CP and L2 Stacks to enhance readers’ perspectives.

References:

https://medium.com/@eternal1997L

https://medium.com/polkadot-network/a-brief-summary-of-everything-substrate-and-polkadot-f1f21071499d

https://tokeneconomy.co/the-state-of-crypto-interoperability-explained-in-pictures-654cfe4cc167

https://research.web3.foundation/Polkadot/overview

https://foresightnews.pro/article/detail/16271

https://v1.cosmos.network/

https://polkadot.network/

https://messari.io/report/ibc-outside-of-cosmos-the-transport-layer?referrer=all-research

https://stack.optimism.io/docs/understand/explainer/#glossary

https://www.techflowpost.com/article/detail_12231.html

https://gov.optimism.io/t/retroactive-delegate-rewards-season-3/5871

https://wiki.polygon.technology/docs/supernets/get-started/what-are-supernets/

https://polygon.technology/blog/introducing-polygon-2-0-the-value-layer-of-the-internet

https://era.zksync.io/docs/reference/concepts/hyperscaling.html#what-are-hyperchains

https://medium.com/offchainlabs

Disclaimer: This report is an original work completed by @sldhdhs3 and @GryphsisAcademy’s students, under the guidance of @Zou_Block and @artoriatech. The authors are solely responsible for all content, which does not necessarily reflect the views of Gryphsis Academy or the organization commissioning the report. Editorial content and decisions are not influenced by readers. Please be aware that the authors may own cryptocurrencies mentioned in this report. This document is for informational purposes only and should not be relied upon as the basis for investment decisions. It is strongly recommended that you conduct your own research and consult with independent financial, tax, and legal advisors before making any investment decisions. Please remember that past performance of any asset does not guarantee future returns.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.