Technical Interpretation of Chainway: How does the Bitcoin Layer 2 project use the concept (1)
Written by: Shew & Faust, geek web3
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. becauseBlockchainThe field iterates quickly, and professional vocabulary or standards are constantly changing in the process of research innovation and project implementation. under such a circumstance,Many projects will use 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 solutions originally active in the Ethereum/Celestia ecosystemBlockchainThe project has also taken advantage of the east wind to catch the "Bitcoin Layer 2" express train and calls itself "Rollup", but its technical solutions often do not meet the standards of Rollup.
but,"Words like "Rollup" have a high degree of recognition, and using the banner of "Rollup" is more conducive to publicity.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 when I took off its "XX Rollup" coat, I saw thatThe working principle of many projects is still simply "client verification" or "side chain", just using the slogan "XX Rollup" to make it convenient for themselves.Although this method of publicity is relatively common, it is often misleading.For the broad masses of people seeking the truth, it will bring more harm than good.
(Nazi Propaganda Minister Goebbels summarized "lying propaganda". This practice is common among many project developers)
So how should we identify this kind of behavior that "plays with the Rollup concept"?
Perhaps, starting from first principles, we can define the solution categories and types of different Layer 2 projects based on standards widely recognized by the West and even the industry.Safetydegree, and functional completeness,Only then can we open the "Kaleidoscope Sharingan" that is used to see flowers in the mist. Or,What solution is adopted is not the most important. The core lies in whether the project can ensure Layer 2 network in terms of mechanism design.SafetyReliable, can it truly empower the BTC mainnet.
Next, we plan toTake Chainway, a Bitcoin Layer 2 made by foreigners, as an example.Analysis of some projects hidden behind the “Rollup” sloganXiaobai NavigationThe essence of "client verification". We can see more clearly that "sovereign rollup" and "client verification" are different from the mainstream meaning in the industry.ZKRollup, or OPRollup etc. rely on smartcontractThere are significant differences in the implemented Rollup scenarios.
Of course, this does not mean that sovereign rollup or client-side verification is inferior to ZK rollup SafetyReliability, everything depends on its specific 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 image labels itself as ZK Rollup, but its real solution is client verification. Currently, it has not yet achieved consensus among off-chain clients or reliable message exchange)
text:Chainway is a WesternCommunityFor the more famous Bitcoin Layer 2 project, many KOLs directly call it “ZK Rollup” when promoting it.In its technical documentation, Chainway positions itself as a "sovereign rollup."Recently Chainway also announced its new project Citrea, claiming to be ZK Rollup based on BitVM. Since Citrea has not yet detailed how its BitVM-based ZK verification scheme is implemented,This article will focus on the technical interpretation of Chainway’s existing solutions.
We can summarize it in one sentenceChainway’s now disclosed technical solution: publish DA data through the Ordinals protocol, using BTC as its DA layer,Publish state change details State diff + ZK Proof to prove the correctness of state changes in Layer1, the effectIt 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 performed by independent clients/nodes under the chain, andChainway’s current code base does not achieve consensus among independent clients off the chain, and officials have not claimed to solve this problem on social media.Therefore, the current technical solution announced by Chainway is essentiallyBelongs to "Client Verification"Type, or 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) concept is used. Sovereign Rollup is actually related to EthereumCommunityEven the mainstream Rollup concept in the industry (intelligentcontract Rollup) is very different. So what is the specific structure of a sovereign Rollup?
actuallyThe 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 it does not require intelligence on Layer1contractTo verify the state transition/cross-chain behavior of Layer 2, essentially just use BTC as the DA layer, and the security model is very close to "client side validation".
certainly,Some sovereign rollup solutions with higher security will rely on the third-party settlement layer under the BTC chain (similar to side chains) to complete state transition verification.And there is a layer of consensus or reliable message delivery between different independent clients/full nodes to reach "consensus" on certain controversial behaviors. butSome sovereign rollup projects are naked "client verification", and there is no reliable message transmission between independent clients/nodes.
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 the modularityBlockchainSeveral terms of narrative are explained as follows:
Execution execution layer: 执行用户交易，更新Blockchain状态，向 DA 层和结算层提交数据
Settlement settlement layer:Verify state transitions at the execution layer, resolve disputes (such as fraud proofs), and provide bridge modules to handle L1-L2 Bridging 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: 确保交易排序的最终性，与 DA 层的职能似乎比较接近（以太坊Community对模块化区块链的分层方式，不包含共识层）
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.
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 data recorded 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)
References:Using the barrel theory to dismantle Bitcoin/Ethereum Layer 2 security model and risk indicators
We can see thatSmart contract Rollup relies heavily on the smart contract on Layer1.For Layer 1 like BTC, which is difficult to support complex business logic, it is basically impossible to construct a Layer 2 that is "aligned" with Ethereum Rollup.
andThe sovereign rollup solution simply 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 the 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 thatSince the settlement layer module is not located on Layer1, sovereign Rollup cannot theoretically implement a bridge with security equivalent to Layer1.Often you have to rely 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 to BTC, but the specific security is questionable.
But the problem is,Bitcoin’s data throughput is extremely low,Each block has a maximum size of 4MB, and the average block generation time is 10 minutes. The converted data throughput is 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.: For example, publish DA data off-chain and store 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 rollup and 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-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. andUnder the sovereign rollup solution, developers need to construct bridge components under the Layer1 chain. The constructed bridge will most likely not be trusted like a smart contract bridge.
BTC DA Structure
In the above, we mentioned that to implement a sovereign rollup based on BTC, 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 method of using OP_0 OP_IF in Ordinals Protocol to implement data writing, and 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 submitted is submitted by the sequencer. .
We also need to pay attention here,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.It is equivalent to clearly distinguishing the transactions initiated when the Chainway sequencer submits data from other transactions on the Bitcoin chain.In the following, we call this kind of data containing DA data andTransactions that meet 16 zeros at the end are "Chainway standard transactions".
So here 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 transaction, 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 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. ChainWay sorter is generating L2 block,It must include "Layer2 standard transactions" that have been disclosed on the BTC chain but not included in the L2 ledger.And summarize it into a Merkle Tree, and write its 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 certificate 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's easy to see,As long as the user can construct a "standard transaction" that meets the restrictions and submit it to the BTC chain, this transaction will eventually be included in the local L2 ledger of the Chainway client. Otherwise, the L2 block issued by the Chainway sequencer will be Rejected by client.
If the cooperation is 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 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 alert broadcast.But currently Chainway has not implemented this yet(At least the currently published information and code base show that it has not implemented this technology).
References:Celestia researchers analyze 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 eventually ensure that "forced transactions" are included in the Layer2 ledger through the contract on Layer1, fully inheriting the censorship resistance of Layer1.Sovereign Rollup obviously cannot keep up with smart contract Rollup in this regard, and its censorship resistance ultimately depends on the off-chain part.
This also determines, "The ideas of "Sovereign Rollup" and "Client Verification" solutions are basically impossible toLike Arbitrum One or Loopring, dydx and Degate,Completely inherits the censorship resistance of Layer1, because whether mandatory transactions can be successfully included in the Layer2 ledger depends on the decisions of entities off the Layer2 chain, and has nothing to do with Layer1 itself.
obviously,ChainwayThis kind of solution relies solely on the free decision-making of off-chain clients.It only inherits the DA reliability of Layer1, but does not fully inherit its censorship resistance.
Recursive ZK proof similar to MINA
In this section, we will further introduce the other components of Chainway, which in addition to using BTC as the DA layer, also implementsRecursive 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,You only need to verify that the latest ZK Proof disclosed on BTC is valid, and you can confirm that the historical data of the entire chain and all state transitions are valid.
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
As summarized at the beginning of this article,Chainway is essentially a sovereign rollup/client verification scheme using BTC as the DA layer.In order to improve the censorship resistance of Rollup, 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.Since it adopts a sovereign rollup solution, it does not explain how it intends to solve the technical details of the cross-chain bridge solution, and it is difficult to judge its final security.
today,Through 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 Layer 2 solution classification and security standards, and functional completeness evaluation standards. Stay tuned for in-depth research!
The article comes from the Internet:Technical Interpretation of Chainway: How does the Bitcoin Layer 2 project use the concept (1)
If the foundation of the beliefs of Bitcoin OG and Satoshi Nakamotoists are problematic, then what is the value of the existence of the blockchain? Written by: Faust & Fog Moon, Geek Web3 Ordinals protocol is a system for numbering satoshis (SATS, the smallest unit of Bitcoin), or a derivative of Bitcoin UTXO as a data storage medium...
相关文章
