Technical Interpretation of Chainway: How the Bitcoin Layer 2 project came about

Author: Shew & Faust, geek web3, consultant: Kevin He, founder of BitVM Chinese community, ex Web3 Tech Head@Huobi

The current Bitcoin Layer 2 track can be said to be in full bloom, with various technical solutions gathered in the melting pot of the BTC ecosystem. Due to the rapid iteration speed of the blockchain field, professional vocabulary or standards are constantly changing in the process of research, innovation and engineering implementation. In this context, many projects will adopt the method of "creating concepts"/"creating concepts" to gain differentiation and attention, which has become an unspoken rule in the industry.

For example, many modular blockchain projects that were originally active in the Ethereum/Celestia ecosystem have also taken advantage of the east wind to catch the "Bitcoin Layer 2" express train and call themselves "Rollup" , but its technical solutions often do not meet Rollup’s standards.

However, words like "Rollup" have a high degree of recognition, and it is more conducive to publicity under the banner of "Rollup". Many project parties are either trying hard (self-proclaimed Rollup), or branching off the mainstream Rollup concept (adding an ambiguous attributive, such as sovereign Rollup).

But if you peel back the cover of "XX Rollup", you can see that the working principle of many projects is still simple "client verification" or "side chain", just relying on the promotion of "XX Rollup" The slogan is for your own convenience. Although this method of propaganda is relatively common, it is often misleading and brings more harm than good to the masses who pursue the truth.

(Nazi Propaganda Minister Goebbels’ summary of “lying propaganda”, this practice is common among many project parties)

How should we identify this What about behavior similar to “rollup concept”?

Perhaps, starting from first principles and defining the solution categories, security levels, and functional completeness of different Layer 2 projects based on standards widely recognized by the West and even the industry, we can start to see the flowers in the smoke. The pair of "Kaleidoscope Sharingan" at that time. In other words, what plan is adopted is not the most important. The core lies in whether the project can ensure the security and reliability of the Layer 2 network in terms of mechanism design, and whether it can truly empower the BTC main network.

Next, we plan to use Chainway, a foreigner, to do this Bitcoin Layer 2 is used as a case to analyze the essence of "client verification" hidden behind the "Rollup" slogan of some projects. We can see more clearly the obvious differences between "Sovereign Rollup" and "Client Verification" and the industry's mainstream ZK Rollup, or OP Rollup and other Rollup solutions that rely on smart contract implementation.

Of course, this does not mean that sovereign Rollup or client-side verification is not as safe and reliable as ZK Rollup. Everything depends on its specific implementation details. Although Chainway is a typical client-verified Layer 2, it proposes an anti-censorship transaction scheme of "triggered in BTC + verified off-chain" and adopts a recursive ZK Proof similar to the MINA public chain, which is ahead of most Bitcoin Layer 2s. .

We believe that the technical research on Chainway is quite valuable and has important reference significance for the majority of Bitcoin Layer 2 observers.

(Chainway’s promotional picture bills itself as ZK Rollup, but its real solution is client verification. At present, it has not yet achieved consensus among off-chain clients or reliable message exchange)< /span>

Text:Chainway is a well-known Bitcoin Layer 2 project in the Western community. Many KOLs directly call it "ZK Rollup" when promoting it, and < strong>In its technical documentation, Chainway positions itself as a "sovereign rollup." Recently Chainway also announced its new project Citrea, which claims to be ZK Rollup based on BitVM. Since Citrea has not yet explained in detail how its BitVM-based ZK verification solution is implemented,this article will focus on the technical interpretation of Chainway’s existing solution.

We can summarizeChainway’s now-public technical solution in one sentence: publishing DA data through the Ordinals protocol, using BTC as its DA layer,< /strong>Publish state change details State diff + ZK Proof to prove the correctness of state changes in Layer1. The effect is equivalent to publishing complete and verifiable transaction data.

(State diff is the change in account status)

However, since Layer1 does not directly verify ZK Proof, the verification work is done by off-chain Independent clients/nodes, andChainway’s current code base does not achieve consensus among independent clients off the chain, and the official has not claimed to solve this problem on social media. So, the technical solution currently announced by Chainway is essentially of the "client-side verification" type, and is even more like an inscription index protocol that supports bridging assets.

The following will mainly introduce the specific technical implementation of Chainway and analyze its security model.

What is sovereign rollup: DA layer releases data + off-chain verification

In Chainway’s technical documentation, Celestia’s sovereign rollup (sovereign rollup) is used concept. And Sovereign Rollup is actually very different from the mainstream Rollup concept (smart contract Rollup) in the Ethereum community and even the industry. So what is the specific structure of sovereign Rollup?

In fact, Sovereign Rollup based on Bitcoin is somewhat similar to - "an off-chain client group/side chain that publishes DA data on the BTC chain". Its biggest feature is that, There is no need for smart contracts on Layer 1 to verify the state transition/cross-chain behavior of Layer 2. Essentially, it just uses BTC as the DA layer, and the security model is very close to "client side validation".

Of course, some sovereign rollup solutions with higher security will rely on the third-party settlement layer under the BTC chain (similar to the side chain) to complete the state transition verification, and There is a layer of consensus or reliable messaging between different independent clients/full nodes to reach "agreement" on certain controversial behaviors. But some sovereign Rollup projects are naked "client verification", and there is no reliable message transmission between independent clients/nodes.

In order to better understand "Sovereignty Rollup" With this unique concept,we can compare sovereign rollups with their corresponding smart contract rollups. Layer 2 on Ethereum is basically a smart contract rollup, such as Arbitrum and StarkNet. The structure of smart contract Rollup can refer to the following figure:

In the above figure, we You can see several terms in the modular blockchain narrative, explained as follows:

Execution execution layer: Execute user transactions, update blockchain status, report to DA layer and settlement Layer submission data

Settlement Settlement Layer: Verify state transitions of the execution layer, resolve disputes (such as fraud proof), and provide bridge modules to handle L1-L2 bridge assets

DA layer: A large bulletin board that receives state transition data submitted by the execution layer and provides this data to anyone without trust

Consensus Consensus layer: Ensuring the finality of transaction ordering seems to be relatively close to the functions of the DA layer (the Ethereum community’s layered approach to modular blockchains does not include the consensus layer)

From In the smart contract Rollup architecture, we see that in addition to the execution layer, the functions of the other three layers are assumed by Ethereum. The figure below shows in more detail the role played by Ethereum in smart contract rollup.

The Rollup contract on Ethereum will receive validity proof (validity proof) or fraud proof (fraud proof) to verify the validity of Layer2 state transition. It is worth mentioning that the Rollup smart contract here is actually the settlement layer entity in the modular blockchain. The settlement layer contract often contains a bridging module, which is used to handle assets bridged from Ethereum to Layer 2.

As for DA, the settlement layer contract can force the sequencer to upload the latest transaction data/status change details to the chain. If DA is not uploaded to the chain, the records on the Rollup contract cannot be updated smoothly. L2 state.

(ZK Rollup or OP Rollup can force DA data to be uploaded to the chain. Without it, the status of the settlement layer record cannot be updated)

We It can be seen that smart contract rollup relies heavily on the smart contract on Layer1. For Layer1 like BTC, which is difficult to support complex business logic, it is basically impossible to construct a Layer2 that is "aligned" with Ethereum Rollup.

The Sovereign Rollup solution does not require the contract on Layer1 to perform state verification/bridging processing. The structure is as shown below:

We can see thatIn sovereign rollup, the node group outside the DA layer serves as the entity for transaction execution and settlement operations, and has a higher degree of freedom. The specific workflow is as follows:

The execution layer of sovereign Rollup Nodes, send transaction data/status change details to the DA layer, while the settlement layer/client manages to obtain the data and perform verification work. It is worth noting that Since the settlement layer module is not located on Layer 1, sovereign rollup cannot theoretically implement a bridge with the same security as Layer 1. It often relies on a notary bridge or a third-party bridge. plan.

Currently, it seems that the implementation of the sovereign rollup/client verification solution is relatively low. It only needs to implement data release on the BTC chain, using a form similar to the Ordinals protocol. As for off-chain verification and off-chain consensus, there is a lot of room for free play. Even many side chains basically become a "BTC-based sovereign rollup" as long as they publish DA data to BTC, but only the specific security Doubtful.

But the problem is that Bitcoin’s data throughput is extremely low. Each block has a maximum of 4MB, and the average block generation time is 10 minutes. This is converted into data throughput. Only 6KB/s. The current Layer 2 solution that calls itself a sovereign Rollup may not be able to publish all DA data on the BTC chain, and will adopt other compromise methods: such as publishing DA data off-chain and storing the datahash in the BTC chain as a "commitment". Or find a way to highly compress DA data (such as State diff+ZK Proof that Chainway claims to use).

But obviously this model does not meet the definition of "sovereign rollup" or serious rollup. It is a variant and its security is open to question. We predict that in the future, most Layer 2 projects under the banner of “Rollup” will not release the complete DA data to the BTC chain.So their practical plans will most likely not be consistent with the white paper. The "ZK Rollup" and "OP Rollup" slogans on the website are not consistent.

Finally, let us briefly summarize the sovereignty Rollup Differences from smart contract Rollup:

First, upgradability. The update iteration of smart contract Rollup involves the update of smart contracts, which requires the development team to use upgradable contracts. The upgrade permissions of this smart contract are generally controlled by the Rollup development team using multi-signature. The upgrade rules of sovereign rollup are similar to the soft and hard forks of conventional blockchains. Nodes can choose the updated version on their own, and different clients can choose whether to accept the upgrade. From this point of view, sovereign rollup is superior to smart contract rollup.

Second, the bridge. The bridge of smart contract Rollup is consistent with trust minimization under ideal conditions, but the upgradeability of the contract will affect its security. Under the Sovereign Rollup scheme, developers need to construct bridge components under the Layer1 chain. In all likelihood, the constructed bridge will not be trusted like a smart contract bridge.

BTC DA Structure

In the above, we mentioned that, To implement a BTC-based sovereign rollup, the core lies in using the Ordinals protocol to use BTC as the DA layer. Chainway uses this solution.

We can observe a DA data submission from the Chainway sequencer, and its transaction hash is:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, The schematic diagram is as follows:

The script code of this transaction draws on the use of OP_0 OP_IF in Ordinals Protocol to implement data The writing plan writes Rollup's DA data into the BTC chain (publishing status changes + ZK Proof is equivalent to publishing original transaction data in terms of security, but the data size can be greatly compressed).

Of course, in addition to DA data, the sequencer also writes some authentication data in the transaction. The most important thing is that the Rollup sequencer uses its own private key to sign the DA data to ensure that the DA Data submission is submitted by the sorter.

We also need to note here that for any transaction involving DA data submission, there are 16 binary 0s at the end of the transaction hash (that is, 2 consecutive bytes are all 0) . Within the code, we can see this restriction:

Previous The random number b715 in the example transaction diagram is to adjust the hashed value of this transaction so that its tail carries a specific 16 zeros. The principle is similar to the need to add a random number nonce when mining Bitcoin, so that the hash The first N bits of are all 0, meeting specific restrictions.

This design is to simplify the difficulty of obtaining DA data. When any node in Layer 2 wants to obtain DA data, it only needs to scan the BTC block, and all the ends are set to 16 0 transactions areequivalent to the transactions initiated when the Chainway sequencer submits data, clearly distinguishing them from other transactions on the Bitcoin chain. In the following, this kind of transaction that contains DA data andsatisfies 16 zeros at the end is called "Chainway standard transaction".

Then comes the point mentioned in the title of this article: How does Chainway achieve censorship resistance? Because the Layer 2 sequencer may deliberately reject a user's transaction request, we must use a special solution to allow users to initiate censorship-resistant transactions.

Faced with this problem, Chainway allows users to initiate “forced transactions”, Forced Transaction. Once the user submits this transaction statement within the BTC block, the Chainway sequencer must process this transaction request at Layer 2, otherwise it will not be able to produce the block normally, or the block will not be recognized by the off-chain client.

The parameter structure of forced transaction is as follows:

This transaction will be submitted to the Bitcoin chain as a "Chainway specification transaction", with 16 zeros at the end of the transaction hash. When the ChainWay sequencer generates an L2 block, it must include the "Layer2 standard transactions" that have been disclosed on the BTC chain but not included in the L2 ledger, and summarize them into a Merkle Tree, with their Merkle root Write L2 block header.

Once a user initiates a forced transaction directly on the BTC chain, the sequencer must process it, otherwise the next valid block cannot be generated. The Chainway client under the BTC chain can first verify the ZK certificate, determine the validity of the L2 block submitted by the sequencer, verify the Merkle root of the L2 block header, and determine whether the sequencer truthfully contains the forced transaction request.

For its workflow, please refer to the following flow chart. Note that due to space limitations, verify_relevant_tx_list in the picture below is missing a conditional judgment:

In short , the Chainway client/node will synchronize the BTC main network block, and scan out the "DA data" released by the Chainway sequencer, confirming that these data are published by the designated sequencer, and indeed contain all submitted to the BTC chain "Chainway Standardized Transactions" on.

It is not difficult to see that as long as the user can construct a "standard transaction" that meets the restrictions and submit it to the BTC chain, the transaction will eventually be included in the local Chainway client. In the L2 ledger, otherwise the L2 block issued by the Chainway sequencer will be rejected by the client.

If coupled with reliableoff-chain consensus/alert messaging, Chainway’s anti-censorship transaction solution is close to the ideal anti-censorship method of sovereign Rollup. . For example, some sovereign rollup solutions have made it clear that when invalid blocks are encountered, Alert alert messages will be broadcast among off-chain clients to enhance security, especially to allow light clients that cannot synchronize complete DA data to know that the network status is abnormal.

If a block does not truthfully contain a "forced transaction", it will obviously trigger an off-chain alarm broadcast, but currently Chainway has not implemented this yet (at least according to the current published information and code library, showing that it does not have the technical implementation to do this).

Even if consensus among off-chain clients/nodes is achieved ,Chainway's "forced transaction" anti-censorship effect is not as good as smart contract rollup such as Arbitrum, because Arbitrum One will ultimately ensure that "forced transactions" are included in the Layer2 ledger through the contract on Layer1, fully inheriting the anti-censorship of Layer1 Censorship, Sovereign Rollup obviously cannot keep up with smart contract Rollup at this point, and its censorship resistance ultimately depends on the off-chain part.

This also determines that the ideas of "Sovereign Rollup" and "Client Verification" solutions are basically unable< /strong>Like Arbitrum One or Loopring, dydx and Degate, complete inherits the censorship resistance of Layer 1, because whether mandatory transactions can be successfully included in the Layer 2 ledger depends on the Layer 2 off-chain The decisions of entities have nothing to do with Layer1 itself.

Obviously, Chainway, a solution that simply relies on the free decision-making of off-chain clients, only inherits the DA reliability of Layer1 and does not have complete Inherit its censorship resistance.

Recursive ZK proof similar to MINA

In this section, we will further introduce other components of Chainway, In addition to using BTC as the DA layer, it also implements a recursive ZK proof similar to MINA. The overall structure is as follows:

The sequencer of the Chainway network processes user transactions Finally, the final ZK proof is generated, together with the state diff of the status change details of different accounts, and published to the BTC chain. The full node will synchronize all historical data of Chainway published on BTC. Each ZK proof must not only prove the state transition process of the current block, but also ensure that the ZK proof of the previous block is valid.

Based on the above scheme, we can find that every time a new proof is generated, the previous proof is actually confirmed, and recursively, the latest ZK proof can guarantee that it will start from the genesis area All ZK proofs at the beginning of the block are valid. This design is similar to MINA.

When a "light client" that only synchronizes block headers, that is, a light node, joins the network, it only needs to verify that the latest ZK Proof disclosed on BTC is valid, and the entire chain can be confirmed Historical data and all state transitions are valid.

If the sequencer does evil and deliberately does not accept forced transactions, or does not use the last ZK proof for recursive proof, the new ZK proof generated cannot be accepted by the client (it will not be generated even if it is generated). recognized), as shown below:

Summary< /h2>

As summarized at the beginning of this article,Chainway is essentially a sovereign rollup/client verification solution using BTC as the DA layer. In order to improve Rollup’s censorship resistance, Chainway introduced the concept of forced transactions. On the other hand, Chainway uses recursive ZK proof technology, so that newly entered nodes can trust the output results of the sequencer more and confirm that the historical data of the entire chain is correct at any time.

Chainway’s current problem is how to trust the cross-chain bridge part. Because it adopts the sovereign Rollup solution, it has not stated how it intends to solve the technical details of the cross-chain bridge solution. It is difficult to judge its ultimate safety.

Today, through an in-depth analysis of Chainway’s technical solutions, we found that the type of technology promoted by the project community is not Rollup in the mainstream sense. Considering that there are currently dozens of Bitcoin Layer 2 projects (maybe hundreds in half a year), in order to reduce everyone’s cognitive cost of technical terms, we will continue to improve the classification and security standards of Layer 2 solutions and complete functions. In-depth research on sexual evaluation standards, so stay tuned!