技术解读Chainway：比特币Layer2项目是怎么蹭概念的（一）

撰文：Shew & Faust，极客 web3

比如说，许多不知活跃于以太坊/Celestia生态的标准化区块链项目，也乘着东风之便，搭上了「比特币 Layer2」的快车，并自封为「Rollup」，但其技术方案往往不符合 Rollup 的标准。

（沙漠宣传部部长戈培尔对「撒谎式宣传」的总结，这种做法在很多项目方身上屡见不鲜）

那我们如何识别这类「蹭 Rollup 概念」的行为呢？

我们认为，对于成为成远的技术调研是比较有价值的，这对于广大比特币 Layer2 观察者来说具有重要的参考意义。

（Chainway的宣传图片，将自己标榜为ZK Rollup，但其真实方案是客户端验证，目前其尚未实现链下客户端间的想法，或可靠的消息交换）

（State diff 就是账户状态的变化量）

下面将主要介绍Chainway的具体技术实现，并分析其安全模型。

何谓主权Rollup：DA层发布数据+链下验证

在Chainway的技术文档中，用到了Celestia的主权Rollup(sovereign rollup)概念。而主权Rollup显然与以太坊社区其实主流的Rollup概念（智能合约Rollup）有天壤之别。那么主权Rollup的具体构造是怎样的呢？

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

In the image above, we can see several terms for the modular blockchain narrative, explained as follows:

Execution execution layer: execute user transactions, update blockchain status, and submit data to the DA layer and settlement layer

Settlement Settlement Layer: Verifies the state transitions of the execution layer, resolves disputes (such as fraud proofs), and provides a bridge module 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: ensures the finality of transaction ordering, and 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 the architecture of the smart contract Rollup, 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 to handle assets bridged from Ethereum to Layer 2.

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 L2 status recorded on the Rollup contract cannot be successfully updated.

(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)

Reference: Using barrel theory to dismantle Bitcoin/Ethereum Layer2 security model and risk indicators

We can see that smart contract rollup relies heavily on smart contracts 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. Its structure is as follows:

We can see that in 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. Its specific workflow is as follows:

The execution layer node of the sovereign Rollup sends 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 Layer1, sovereign rollup cannot theoretically implement a bridge with the same security as Layer1, and often relies on notary bridges or third-party bridging solutions.

At present, 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 "BTC-based sovereign rollups" as long as they publish DA data on BTC, but the specific security is questionable.

But the problem is that Bitcoin’s data throughput is extremely low. Each block is a maximum of 4MB, and the average block generation time is 10 minutes. This translates into a data throughput of only 6KB/s. The Layer 2 solution that now 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 on 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 complete DA data to the BTC chain, so their practical plans will most likely be the same as the “ZK Rollup” and “OP Rollup” in the white paper. "The slogan does not match.

Finally, let us briefly summarize the differences between sovereign rollups and smart contract rollups:

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-signatures. 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 smart contract Rollup bridge is trust-minimizing under ideal conditions, but the upgradability of the contract will affect its security. Under the sovereign rollup solution, 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 the core of realizing sovereign rollup based on BTC is to use 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 Ordinals Protocol's scheme of using OP_0 OP_IF to implement data writing, and writes Rollup's DA data into the BTC chain (publishing status changes + ZK Proof, which is equivalent to publishing the original transaction in terms of security) data, 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 submitted is submitted by the sequencer. .

Here we also need to note 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). Inside the code we can see this limitation:

The purpose of the random number b715 in the previous 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 first N bits of the hash are all 0, which meets certain 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 for all transactions with 16 zeros at the end, which is equivalent to launching when the Chainway sequencer submits data. Transactions are clearly distinguished from other transactions on the Bitcoin chain. In the following, this kind of transaction that contains DA data and satisfies 16 zeros at the end is called "Chainway standard transaction".

So let’s get to the point mentioned in the title of this article: How does Chainway achieve censorship resistance? Because the Layer 2 sequencer may intentionally 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 in Layer2, 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 the forced transaction is as follows:

This transaction will be submitted to the Bitcoin chain as a "Chainway canonical transaction", with 16 zeros at the end of the transaction hash. When the ChainWay sequencer generates an L2 block, it must include the "Layer2 specification transactions" that have been disclosed on the BTC chain but not included in the L2 ledger, and summarize them into a Merkle Tree, and write their Merkle root into the 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 proof to 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.

Its workflow can be referred to the following flow chart. Note that due to space limitations, verify_relevant_tx_list in the figure 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" published by the Chainway sequencer to confirm that these data are published by the designated sequencer and indeed contain all submitted to BTC "Chainway standardized transactions" on the chain.

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 L2 ledger of the Chainway client, otherwise the Chainway sequencer will L2 block will be rejected by the client.

If coupled with reliable off-chain consensus/alert messaging, Chainway’s censorship-resistant transaction solution approaches the censorship-resistant method of the ideal sovereign Rollup. For example, some sovereign rollup solutions have made it clear that when an invalid block is encountered, Alert alert information will be broadcast among off-chain clients to enhance security, especially allowing 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 (at least the current published information and code base show that it has not implemented the technology for this).

Reference: Celestia researcher analyzes 6 Rollup variants: Sequencer=aggregator +Header generator

Even if consensus among off-chain clients/nodes is achieved, the anti-censorship effect of Chainway's "forced transactions" is not as good as smart contract rollup such as Arbitrum, because Arbitrum One will ultimately ensure that "forced transactions" are included through the contract on Layer1 Entering the Layer 2 ledger, it fully inherits the censorship resistance of Layer 1. Sovereign Rollup obviously cannot match the smart contract Rollup in this regard, 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 to fully inherit the censorship resistance of Layer 1 like Arbitrum One or Loopring, dydx and Degate, because whether forced transactions can be smoothly included in Layer 2 The ledger depends on the decisions of entities off the Layer2 chain and has nothing to do with Layer1 itself.

Obviously, Chainway, a solution that relies solely on the free decision-making of off-chain clients, only inherits the DA reliability of Layer1, but does not fully inherit its censorship resistance.

MINA-like recursive ZK proof

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

After processing user transactions, the Chainway network's sequencer generates the final ZK proof, together with the state diff of the status change details of different accounts, and publishes it 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. Recursively, the latest ZK proof can guarantee that all ZK proofs starting from the genesis 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 it can confirm that the historical data of the entire chain and all state transitions are valid of.

If the sequencer acts 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 recognized even if it is generated), as shown below:

Summarize

正如本文开头所总结的，Chainway 本质上是一个使用 BTC 作为 DA 层的主权 Rollup/客户端验证解决方案。

为了提高 Rollup 的抗审查能力，成威引入了强制交易的概念。

另一方面，成威采用递归ZK证明技术，让新进入的节点能够更加信任定序器的输出结果，随时确认全链的历史数据是正确的。

目前Chainway面临的问题是如何信任跨链桥接部分。

由于其采用的是主权rollup方案，因此并未说明打算如何解决跨链桥方案的技术细节，很难判断其最终的安全性。

今天，通过深入分析成为成为的技术方案，我们发现项目社区推广的技术类型并非主流意义上的 Rollup。

考虑到目前比特币 Layer 2 项目有几十个（半年可能几百个），为了降低大家对技术术语的认知成本，我们将持续完善 Layer 2 解决方案分类和安全标准，以及功能完整性评估标准。

敬请期待深入研究！

标签：技术 比特币 项目 LAYER