Technical Interpretation of Chainway: How Bitcoin Layer2 Projects Leverage Concepts

Introduction:

The current Bitcoin Layer2 scene is bustling with diverse technological solutions converging in the BTC ecosystem’s melting pot. Given the rapid pace of iteration in the blockchain field, where professional vocabulary and standards continuously evolve through research, innovation, and engineering implementation, many projects resort to “concept creation” or “concept hitchhiking” for differentiation and attention, becoming an unspoken rule within the industry. For instance, several modular blockchain projects initially active within the Ethereum/Celestia ecosystem have jumped on the “Bitcoin Layer2” bandwagon, dubbing themselves as “Rollups,” despite their technical solutions often not meeting the Rollup standards. However, the term “Rollup” carries significant recognition, making it advantageous for promotional purposes. Many project operators either forcefully label themselves as Rollups or fork the mainstream Rollup concept with vague qualifiers, such as “Sovereign Rollup.” Peeling back the layers of these “XX Rollups,” many projects are essentially based on “client-side validation” or “sidechains,” merely using the “XX Rollup” slogan for convenience. Although this promotional strategy is common, it tends to be misleading, causing more harm than good to those seeking the truth.

(This approach, summarized by Nazi Propaganda Minister Goebbels as “lie-based propaganda,” is frequently observed among project operators.) How then can we discern such “Rollup concept hitchhiking” behavior? Perhaps, starting with first principles, defining different Layer2 project categories and their security levels and functionalities based on widely accepted standards in the West and across the industry, could offer clarity. It’s not necessarily about the chosen solution; the core lies in whether the project’s mechanism design ensures the security and reliability of the Layer2 network and truly empowers the BTC mainnet.

This article will use Chainway, a Bitcoin Layer2 project, as a case study to dissect the “client-side validation” nature hidden behind some projects’ “Rollup” slogans. We aim to clearly distinguish between “Sovereign Rollup” and “client-side validation,” and the significant differences from industry-standard ZKRollups or OPRollups that rely on smart contracts. This is not to say that Sovereign Rollups or client-side validations are inferior to ZK Rollups in security and reliability; it all depends on their specific implementation details. Chainway, typically a client-side validation Layer2, has proposed an anti-censorship transaction scheme triggered on BTC with off-chain validation, employing recursive ZK Proofs similar to those used by the MINA public chain, positioning it ahead of many Bitcoin Layer2 projects. We believe that researching Chainway’s technology is valuable, offering significant insights for Bitcoin Layer2 observers. (Chainway’s promotional images brand it as a ZK Rollup, but its old solution was client-side validation, with ZKR being another project of theirs. Currently, it has not achieved off-chain client consensus or reliable message exchange.)

Main Text: Chainway is a well-known Bitcoin Layer2 project in the Western community, often referred to as a “ZK Rollup” by many KOLs, while its technical documentation positions it as a “Sovereign Rollup.” Recently, Chainway also announced its new project, Citrea, claiming it to be a ZK Rollup based on BitVM. However, since Citrea has yet to detail its ZK verification solution based on BitVM, this article will focus on the technical interpretation of Chainway’s previous solutions. In summary, Chainway’s publicly disclosed technical solution involves publishing DA data through the Ordinals protocol, using BTC as its DA layer, and publishing state change details (State diff) + ZK Proof verifying the correctness of state changes on Layer1, equivalent to publishing complete, verifiable transaction data. However, because Layer1 does not directly verify ZK Proofs, with verification conducted by independent clients/nodes off-chain, and Chainway’s current codebase has not achieved consensus among off-chain clients, nor has it claimed to solve this issue on social media, Chainway’s publicly disclosed technical solution essentially belongs to the “client-side validation” category, even resembling a cryptographically indexed protocol supporting asset bridging. The following sections will introduce Chainway’s specific technical implementation and analyze its security model.

What is a Sovereign Rollup: Data Availability (DA) Layer Publishing + Off-chain Verification

In Chainway’s technical documentation, the concept of a Sovereign Rollup from Celestia is used. A Sovereign Rollup is fundamentally different from the mainstream Rollup concept within the Ethereum community and the broader industry (smart contract Rollup). So, what exactly is the structure of a Sovereign Rollup?

In essence, a Sovereign Rollup based on Bitcoin is somewhat akin to an “off-chain client group/sidechain publishing DA data on the BTC blockchain.” Its main characteristic is that it does not require smart contracts on Layer 1 to verify state transitions/cross-chain actions for Layer 2. Essentially, it uses BTC as the DA layer, and its security model is largely similar to “client-side validation.” Of course, some more secure Sovereign Rollup solutions rely on a third-party settlement layer off the Bitcoin chain (similar to a sidechain) to perform state transition verifications. Additionally, among different independent clients/full nodes, there exists a level of consensus or reliable message passing to reach an “agreement” on certain contentious actions. However, some Sovereign Rollup projects are purely based on “client-side validation,” lacking any reliable message passing between independent clients/nodes.

To better understand the unique concept of “Sovereign Rollup,” it’s helpful to compare it with its counterpart, the smart contract Rollup. On Ethereum, Layer 2 solutions are predominantly smart contract Rollups, such as Arbitrum and StarkNet. The structure of a smart contract Rollup can be visualized in the following diagram:

(Imagine a diagram here)

In the diagram, we can see several terms related to the modular blockchain narrative, explained as follows:

• Execution Layer: Executes user transactions, updates blockchain state, and submits data to the DA layer and settlement layer.

• Settlement Layer: Verifies state transitions from the execution layer, resolves disputes (such as fraud proofs), and provides a bridge module for handling L1-L2 bridging assets.

• Data Availability (DA) Layer: Acts like a large bulletin board, receiving state transition data submitted by the execution layer and providing this data in a trustless manner to anyone.

• Consensus Layer: Ensures the finality of transaction ordering. Its function seems somewhat close to that of the DA layer (the Ethereum community’s approach to modular blockchain layering does not include a consensus layer).
  
  From the architecture of smart contract Rollups, we see that Ethereum assumes the role of the last three layers, besides the execution layer. Another diagram could provide a more detailed view of the roles Ethereum plays in smart contract Rollups.
  
  In contrast, Sovereign Rollups differ significantly in that they decentralize some of these responsibilities away from a monolithic blockchain like Ethereum. Specifically, they do not rely on smart contracts on the base layer (Layer 1) for verifying state transitions or handling disputes. Instead, these tasks are managed by off-chain clients or through a third-party settlement layer, emphasizing a different approach to achieving scalability and security in blockchain systems.

Rollup contracts on Ethereum receive either validity proofs or fraud proofs to verify the validity of Layer 2 state transitions. It’s worth mentioning that the Rollup smart contracts act as the settlement layer entities in modular blockchain architecture. The settlement layer contracts often include bridging modules to handle assets bridged from Ethereum to Layer 2. For Data Availability (DA), settlement layer contracts can mandate the Sequencer to post the latest transaction data/state change details on-chain. Without posting DA on-chain, it’s impossible to successfully update the L2 state recorded in the Rollup contracts.

(ZK Rollup or Optimistic Rollup can enforce DA data to be posted on-chain; without it, the state recorded in the settlement layer cannot be updated.) From analyzing the security model and risk indicators of Bitcoin/Ethereum Layer 2 solutions with the barrel theory, it’s clear that smart contract Rollups heavily rely on Layer 1 smart contracts. For a Layer 1 like BTC, which struggles to support complex business logic, constructing a Layer 2 that aligns with Ethereum Rollups is essentially impossible. Sovereign Rollup solutions, on the other hand, do not require contracts on Layer 1 for state verification/bridging. Their architecture is as follows: (Here, the description of the architecture is missing, implying that an illustration or further details were intended to be included but are not provided in the text.)

In sovereign Rollups, nodes outside the Data Availability (DA) layer serve as the entities for transaction execution and settlement operations, offering a higher degree of freedom. The workflow is as follows:

Nodes in the execution layer of the sovereign Rollup send transaction data/state change details to the DA layer, while the settlement layer/clients strive to obtain and verify the data. It is important to note that since the settlement layer module is not located on Layer 1, sovereign Rollups, in theory, cannot achieve bridges with security equivalent to Layer 1. They often rely on notary bridges or third-party bridging solutions. Currently, the implementation of sovereign Rollup/client verification schemes is relatively simple, requiring only the publication of data on the Bitcoin (BTC) chain using a protocol similar to Ordinals. As for off-chain verification and consensus, there is a great deal of flexibility. In fact, many sidechains simply publish DA data on the BTC chain, essentially becoming “BTC-based sovereign Rollups,” though the specific security is questionable. However, the issue is that Bitcoin’s data throughput is extremely low, with a maximum of 4MB per block and an average block time of 10 minutes, translating to a data throughput of just 6KB/s. Layer 2 solutions claiming to be sovereign Rollups may not be able to publish all DA data on the BTC chain, hence they may opt for alternative methods, such as publishing DA data off-chain and storing the datahash on the BTC chain as a form of “commitment,” or finding a way to highly compress DA data (e.g., using State diff + ZK Proof as claimed by Chainway). Clearly, this mode does not conform to the definition of “sovereign Rollup” or a proper Rollup, representing a variant whose security is questionable. We predict that most Layer 2 projects bearing the “Rollup” banner will ultimately not publish all DA data on the BTC chain, so their practical solutions will likely not match the “ZK Rollup” or “OP Rollup” claims made in their whitepapers.

Finally, let’s briefly summarize the differences between sovereign Rollups and smart contract Rollups:

1. Upgradability: The update iterations of smart contract Rollups involve updating the smart contracts, requiring the development team to use upgradable contracts. This kind of smart contract upgrade authority is generally controlled by the Rollup development team through multi-signature. In contrast, the upgrade rules for sovereign Rollups are similar to conventional blockchain soft and hard forks, where nodes can choose to update versions independently, and different clients can choose whether to accept the upgrade. From this perspective, sovereign Rollups are superior to smart contract Rollups in terms of upgradability.

2. Bridges: In ideal conditions, the bridges for smart contract Rollups conform to minimal trust, but the upgradability of contracts can affect their security. Under the sovereign Rollup scheme, developers need to construct bridging components under the Layer 1 chain themselves, and the bridges built are likely to trust less than smart contract bridges.

BTC DA Structure

In the above text, we mentioned that to implement a sovereign Rollup based on BTC, the core lies in using the Ordinals protocol to make BTC serve as the Data Availability (DA) layer. Chainway has adopted this solution.

We can examine a DA data submission from the Chainway sequencer, with the transaction hash being:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, illustrated as follows:

This transaction script borrows from the Ordinals Protocol’s approach of using OP_0 OP_IF for data writing to write the Rollup’s DA (Data Availability) data onto the BTC chain. This involves publishing state changes and ZK Proofs, which is equivalent in security to publishing the original transaction data but allows for significant data size reduction. In addition to the DA data, the sequencer also writes some authentication data into the transaction, with the most crucial being the Rollup sequencer signing the DA data with its private key to ensure the submission comes from the sequencer. It’s important to note that any transaction involving the submission of DA data has 16 binary zeros at the end of the transaction hash (i.e., two consecutive bytes are zero). This restriction can be seen in the code:

In the example transaction graph mentioned previously, the random number “b715” is used to adjust the hash value of the transaction so that its tail carries a specific 16 zeros. This principle is similar to Bitcoin mining, where a random number nonce is added to make the hash’s leading N bits all zeros, meeting specific constraint conditions. This design aims to simplify the difficulty of obtaining DA (Data Availability) data. When any Layer2 node wants to access DA data, it only needs to scan the BTC (Bitcoin) block for all transactions set to end with 16 zeros, effectively distinguishing the transactions initiated by the Chainway sorter when submitting data from other transactions on the Bitcoin blockchain. In the following text, such transactions containing DA data and meeting the requirement of ending with 16 zeros are referred to as “Chainway standard transactions.” The focus of this article is on how Chainway achieves censorship resistance. Since a Layer2 sorter might deliberately refuse a transaction request from a specific user, a special scheme must be employed to allow users to initiate transactions that resist censorship. In response to this issue, Chainway allows users to launch “Forced Transactions.” Once a user submits this transaction declaration within a BTC block, the Chainway sorter must process this transaction request on Layer2; otherwise, it will be unable to normally produce a block, or the block produced will not be recognized by off-chain clients. The parameter structure of the forced transaction is as follows:

This transaction will be submitted to the Bitcoin blockchain as a “Chainway Specification Transaction,” with the transaction hash ending in 16 zeros. The ChainWay sorter, when generating L2 blocks, must include “Layer2 Specification Transactions” that have been disclosed on the BTC blockchain but not yet recorded in the L2 ledger, and aggregate them into a Merkle Tree, writing its Merkle root into the L2 block header. Once a user initiates a forceful transaction directly on the BTC blockchain, the sorter must process it; otherwise, it cannot generate the next valid block. The Chainway client off the BTC chain can first verify the ZK proof to determine the validity of the L2 block submitted by the sorter, check the Merkle root of the L2 block header, and judge whether the sorter has truthfully included the forceful transaction request. The workflow can be referred to the following flowchart. Note that, due to space limitations, the diagram below is missing a condition judgment in verify_relevant_tx_list:

In summary, the Chainway client/node syncs with the BTC mainnet blocks and scans for “DA data” published by the Chainway sorter from them. It verifies that these data are published by the designated sorter and indeed contain all the “Chainway standard transactions” submitted to the BTC chain. It is evident that as long as users can construct a transaction that meets the specified criteria as a “standard transaction” and submit it to the BTC chain, this transaction will eventually be included in the Chainway client’s local L2 ledger. Otherwise, the L2 block released by the Chainway sorter will be rejected by the client. If combined with a reliable off-chain consensus/alert message transmission, Chainway’s anti-censorship transaction scheme approaches the ideal anti-censorship method of sovereign Rollups. For example, some sovereign Rollup solutions have explicitly stated that in the event of an invalid block, Alert warning messages would be broadcasted among off-chain clients to enhance security, especially letting light clients that cannot sync complete DA data know about network anomalies. If a block does not truthfully include “mandatory transactions,” it will obviously trigger an off-chain alert broadcast. However, Chainway has not yet implemented this aspect (at least the currently published materials and code repositories show that it has not undertaken the technical implementation of this part).

Reference material: Celestia researchers analyze 6 types of Rollup variants: Sequencer=Aggregator+Header Generator. Even with the consensus achieved between off-chain clients/nodes, the anti-censorship effectiveness of Chainway’s “forced transactions” is not as robust as that of smart contract Rollups like Arbitrum, because Arbitrum One will eventually ensure “forced transactions” are included in the Layer2 ledger through contracts on Layer1, fully inheriting Layer1’s anti-censorship properties. Sovereign Rollups clearly cannot match smart contract Rollups in this aspect, as their anti-censorship effectiveness ultimately depends on the off-chain components. This also determines that the approach of “Sovereign Rollups” and “client verification” schemes fundamentally cannot inherit Layer1’s anti-censorship properties in full, like Arbitrum One, Loopring, dydx, and Degate, because whether forced transactions can be smoothly included in the Layer2 ledger depends on the decisions of Layer2 off-chain entities, unrelated to Layer1 itself. Evidently, Chainway’s approach, which solely relies on the discretion of off-chain clients, only inherits the DA reliability of Layer1, not its full anti-censorship properties. Similar to MINA’s recursive ZK proofs.

In this section, we will further introduce other components of Chainway, which, besides using BTC as the DA layer, also implemented recursive ZK proofs similar to MINA. Its overall structure is illustrated in the following diagram:

The sorter in the Chainway network, after processing user transactions, generates the final ZK (Zero-Knowledge) proof along with the details of state changes (state diff) for different accounts and publishes them on the Bitcoin (BTC) blockchain. Full nodes will sync all historical data of Chainway published on the BTC blockchain. Each ZK proof not only has to prove the state transition process of the current block but also ensure the validity of the ZK proof of the previous block. Based on this scheme, we can see that each time a new proof is generated, it essentially confirms the previous proof in a recursive manner, and the latest ZK proof can guarantee the validity of all ZK proofs starting from the genesis block. This design is similar to that of MINA. When a “light client” that only syncs block headers, also known as a light node, joins the network, it only needs to verify the validity of the latest ZK Proof disclosed on the BTC blockchain to confirm that the entire chain’s historical data and all state transitions are valid. If the sorter acts maliciously, intentionally refusing to accept mandatory transactions or failing to use the previous ZK proof for recursive proving, then the newly generated ZK proof cannot be accepted by the client (even if generated, it is not recognized), as shown in the diagram below:

Summary

As summarized at the beginning of this article, Chainway is fundamentally a sovereign Rollup/client verification scheme that uses BTC as its Data Availability (DA) layer. To enhance the censorship resistance of the Rollup, Chainway introduces the concept of forced transactions. On the other hand, Chainway employs recursive ZK-proof technology, enabling new nodes to trust the output of the sequencer more and verify the accuracy of the entire chain’s historical data at any time. The current issue with Chainway lies in the trust mechanism of its cross-chain bridge. Since it adopts a sovereign Rollup approach without detailing how it plans to address technical specifics in its cross-chain bridge solution, it’s challenging to judge its ultimate security.

Today, by delving into the technical solution of Chainway, we discovered that the technology type promoted by the project’s community is not a Rollup in the mainstream sense. Considering that there are already dozens of Bitcoin Layer2 projects (which could reach hundreds in half a year), to reduce the cognitive cost of technical terminology, we will continue to conduct in-depth research on the classification of Layer2 solutions and standards for security, functionality completeness, and evaluation. Stay tuned!

Disclaimer：

1. This article is reprinted from [极客 Web3]. All copyrights belong to the original author [Shew & Faust，极客web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.