Analysis of B^2 new version technical roadmap: The Necessity of Off-Chain DA and Verification Layers for Bitcoin

Summary:

· B^2 Network has established a Data Availability (DA) layer known as B^2 Hub within the Bitcoin chain, drawing inspiration from Celestia’s concepts. This DA layer network implements data sampling and erasure coding to ensure rapid distribution of new data to numerous external nodes and to prevent data withholding. Additionally, the Committer within the B^2 Hub network is responsible for uploading the storage index and data hash of DA data to the Bitcoin chain for public access.

. To alleviate the burden on DA layer nodes, historical data in B^2 Hub is not permanently retained. Consequently, B^2 has endeavored to reconstruct a storage network, employing a storage incentivization mechanism akin to Arweave to incentivize more nodes to store comprehensive historical data sets in exchange for storage rewards；

· Regarding status verification, B^2 adopts a hybrid verification approach to validate ZK proofs off-chain and leverages the bitVM concept to challenge ZK proof verification traces on-chain. The safety of the B^2 network is ensured when a challenger node initiates a challenge upon detecting an error, aligning with the trust model of the fraud-proof protocol. However, due to the utilization of ZK proofs, this status verification process is essentially hybrid in nature;

·In line with B^2 Network’s future roadmap, the EVM-compatible B^2 Hub has the potential to serve as an off-chain verification layer and DA layer connecting multiple Bitcoin Layer 2 solutions. It aims to evolve into a Bitcoin off-chain functional expansion layer akin to BTCKB. Given Bitcoin’s limitations in supporting various scenarios, the development of an off-chain functional expansion layer is anticipated to become a prevalent practice within the Layer 2 ecosystem.

B^2 Hub: universal Data Availability (DA) layer and verification layer within the Bitcoin chain

The current Bitcoin ecosystem resembles a vast expanse of opportunities and risks, where the aftermath of the Summer of Inscriptions has breathed new life into this domain, akin to fertile untouched soil with the scent of wealth lingering in the air. The advent of Bitcoin Layer 2 earlier this year has transformed this once desolate landscape into a hub of aspirations for numerous visionaries.

Returning to the crux of the matter: the definition of Layer 2 remains a point of contention among individuals. Is it a side chain? An indexer? Does the term Layer 2 encompass chains that establish connections? Can a simple plug-in dependent on Bitcoin and Ethereum qualify as a Layer? These inquiries resemble unsolved equations without a definitive solution.

According to the perspectives of the Ethereum and Celestia communities, Layer 2 represents a distinct instance of a modular blockchain. In this context, a close interdependence exists between the so-called “second layer” and “first layer.” The security of Layer 1 can be partially or significantly inherited by the second layer network. Security itself encompasses various subcategories, including DA, status verification, withdrawal verification, censorship resistance, and resistance to reorganization.

Given the inherent limitations of the Bitcoin network, it is not inherently conducive to supporting a comprehensive Layer 2 network. For instance, in terms of DA, Bitcoin’s data processing capacity significantly lags behind that of Ethereum. With an average block generation time of 10 minutes, Bitcoin’s maximum data processing rate is merely 6.8KB/s, approximately 1/20th of Ethereum’s capacity. Consequently, the congested block space results in elevated costs for data publication.

(The cost of publishing data in a Bitcoin block can even reach $5 per KB)

If Layer 2 directly publishes newly added transaction data to the Bitcoin block, it will not achieve high throughput or low transaction fees. To address this, one approach is to compress the data significantly before uploading it to the Bitcoin block. Citrea currently employs this method, stating that they will upload state changes (state diff) occurring across multiple accounts to the Bitcoin chain, accompanied by corresponding ZK certificates over a specific period.

This enables anyone to verify the validity of the state diff and ZKP downloaded from the Bitcoin main network while maintaining lightweight data on the chain.

(The former Polygon Hermez white paper explains the principle of the above compression scheme)

Despite the significant data size compression achieved by this method, it may encounter bottlenecks in scenarios where numerous transactions lead to status changes in many accounts within a short period. While lighter than directly uploading individual transaction data, uploading account changes still incurs substantial data release costs.

As a result, many Bitcoin Layer 2 solutions opt not to upload DA data to the Bitcoin main network and instead utilize third-party DA layers like Celestia. In contrast, B^2 implements a different approach by establishing a Data Availability (DA) network directly under the chain, known as B^2 Hub. In this design, crucial data such as transaction data or state diffs are stored off-chain, with only their storage indexes and data hashes (referred to as data for simplicity) uploaded to the Bitcoin mainnet.

These data hashes and storage indexes are recorded on the Bitcoin chain akin to inscriptions. By running a Bitcoin node, individuals can locally access the data hash and storage index. Using the index value, they can retrieve the original data from B^2’s off-chain DA or storage layer. The data hash allows verification of the correctness of data obtained from the off-chain DA layer against the corresponding hash on the Bitcoin chain. This straightforward approach enables Layer 2 solutions to mitigate reliance on the Bitcoin mainnet for DA issues, reduce transaction costs, and achieve high throughput.

However, it is crucial to acknowledge that third-party DA platforms under the chain may engage in data withholding practices, preventing external access to new data—a phenomenon known as a “data withholding attack.” Various DA solutions address this issue differently, with a shared goal of disseminating data rapidly and widely to prevent a select few nodes from controlling data access permissions.

According to B^2 Network’s official new roadmap, its DA solution draws on Celestia.In the latter design, third-party data providers will continuously provide data to the Celestia network. Celestia block producers will organize these data fragments into the form of Merkle Tree, stuff them into TIA blocks, and broadcast them to the network. Validator/full node.

Since there is a lot of data and the blocks are relatively large, most people cannot afford to run full nodes and can only run light nodes. The light node does not synchronize the complete block, but only synchronizes a block header with the root of the Mekrle Tree written on it.

According to B^2 Network’s latest roadmap, its DA solution draws inspiration from Celestia. Under this design, external data providers continuously supply data to the Celestia network. Block producers within Celestia organize these data fragments into a Merkle Tree structure, embed them into TIA blocks, and disseminate them to the network’s validators and full nodes. Due to the substantial volume of data and large block sizes, many individuals opt to run light nodes instead of full nodes. Light nodes synchronize only block headers containing the Merkle Tree root.

While light nodes lack a comprehensive view of the Merkle Tree and cannot verify new data content, they can request specific leaf nodes from full nodes. Full nodes provide the requested leaf nodes along with corresponding Merkle Proofs to convince light nodes of their existence within the Celestia block’s Merkle Tree, ensuring they are not fabricated data.

(Image source: W3 Hitchhiker)

In the Celestia network, there exists a multitude of light nodes that engage in high-frequency data sampling from various full nodes. These light nodes randomly select specific data fragments from the Merkle Tree and disseminate them to other connected nodes swiftly and efficiently, aiming to distribute data to a wide audience of people and devices. This approach facilitates rapid data dissemination, ensuring that a sufficient number of nodes promptly receive the latest data, thereby eliminating the need to rely on a limited group of data providers. This fundamental objective underscores the core essence of Data Availability (DA) and data distribution.

However, despite the effectiveness of the aforementioned solution in enabling swift data access, it does not guarantee the integrity of the data source. For instance, a Celestia block producer could potentially insert erroneous data into a block, complicating efforts to reconstruct the complete and accurate dataset. Even if people obtain all the data fragments in the block, they cannot restore the complete data set that “should be included”.(Note: The word “should” is important here).

Moreover, in scenarios where certain transaction data remains undisclosed to external parties, withholding a mere 1% of the data fragments can impede outsiders from reconstructing the entire dataset—a situation reminiscent of data withholding attacks.

In the context outlined above, understanding data availability pertains to whether transaction data within a block is complete, accessible, and readily shareable for verification purposes. Contrary to common perception, availability does not solely denote the accessibility of blockchain historical data to external entities. Accordingly, Celestia officials and L2BEAT founders advocate renaming data availability as “data release,” signifying the publication of a comprehensive and accessible transaction dataset within a block.

To address the issue of data withholding attacks, Celestia employs two-dimensional erasure coding. If at least 1/4 of the data fragments (erasure codes) within a block are valid, individuals can reconstruct the original dataset. However, if a block producer inserts 3/4 of erroneous data fragments, reconstructing the dataset becomes unfeasible. Notably, an excessive presence of junk data in a block can be readily identified by light nodes, acting as a deterrent against malicious activities by block producers.

By implementing this solution, Celestia effectively mitigates data withholding on its data distribution platform. B^2 Network plans to utilize Celestia’s data sampling methodology as a fundamental reference point in the future, potentially integrating cryptographic technologies like KZG commitment to enhance the efficiency and trustworthiness of data sampling and verification processes conducted by light nodes.

It is crucial to recognize that while the aforementioned solution addresses data retention within the DA platform itself, in the Layer 2 infrastructure, both the DA platform and the Sequencer possess data retention capabilities. In workflows like B^2 Network’s, the Sequencer generates new data by organizing and processing user transactions and resulting status changes into batches before transmitting them to B^2 Hub nodes serving as the DA layer.

In instances where anomalies arise within a batch generated by the Sequencer, there is a risk of data withholding or other malicious activities. Consequently, upon receiving the batch, B^2 Hub’s DA network meticulously verifies its contents and rejects any problematic batches. Thus, B^2 Hub not only functions as a DA layer akin to Celestia but also operates as an off-chain verification layer similar to CKB in the RGB++ protocol.

(Incomplete B^2 Network underlying structure diagram)

In accordance with B^2 Network’s latest technology roadmap, once B^2 Hub receives and verifies a batch, it retains it for a specific period before expiring and removing it from the local node. To address data obsolescence and loss concerns similar to EIP-4844, B^2 Network establishes a network of storage nodes tasked with permanently storing batch data for easy retrieval of historical data when needed.

However, individuals are unlikely to operate a B^2 storage node without a compelling reason. To encourage more participants to run storage nodes and enhance the network’s trustlessness, an incentive mechanism must be established. Implementing such a mechanism necessitates measures to prevent fraudulent activities. For instance, if an incentive system rewards individuals who store data locally on their devices, there is a risk of dishonest behavior where someone deletes part of the data post-download while falsely claiming that their stored data is complete—an all too common form of cheating.

Filecoin employs proof protocols known as PoRep and PoSt, enabling storage nodes to provide storage certificates as evidence to demonstrate that they have indeed securely stored data within a specified timeframe. However, this storage proof approach involves generating ZK proofs, which are computationally intensive and place significant hardware demands on storage nodes, potentially rendering it economically unfeasible.

In the latest technology roadmap of B^2 Network, storage nodes will implement a mechanism akin to Arweave, competing for the opportunity to produce blocks to earn token incentives. If a storage node covertly deletes data, its likelihood of becoming the next block producer diminishes. Nodes preserving the most data stand a higher chance of successfully producing blocks and receiving greater rewards. Consequently, it is advantageous for most storage nodes to maintain the complete historical dataset to optimize their block production prospects.

State verification scheme mixed with ZK and fraud proof

Earlier, we elaborated on the Data Availability (DA) solution of B^2 Network, and now we will delve into its state verification mechanism. The term “state verification scheme” pertains to how Layer 2 ensures a sufficiently “trustless” state transition.

(The L2BEAT website evaluates the five major security indicators for Scroll. State Validation refers to the state verification scheme)

As highlighted on the L2BEAT website, which evaluates the security indicators for Scroll, State Validation specifically addresses the state verification scheme. In B^2 Network and the majority of Layer 2 processes, new data is originated by the sequencer. This entity consolidates and processes user-initiated transactions along with their resulting status changes post-execution. These modifications are bundled into batches and disseminated to various nodes within the Layer 2 network, encompassing standard Layer 2 full nodes and B^2 Hub nodes.

Upon reception of Batch data, the B^2 Hub node meticulously parses and verifies its contents, encompassing the previously mentioned “status verification.” Essentially, state verification entails validating the accuracy of the “state changes post-transaction execution” documented in the sequencer-generated batch. Any erroneous status within a Batch prompts rejection by the B^2 Hub node.

Functioning as a Proof-of-Stake (POS) public chain, B^2 Hub distinguishes between block producers and verifiers. Periodically, B^2 Hub’s block producers generate new blocks and disseminate them to other nodes (validators). These blocks encapsulate Batch data submitted by the sequencer, mirroring a process akin to Celestia. External nodes frequently request data fragments from the B^2 Hub node, facilitating the distribution of Batch data to numerous node devices, including the aforementioned storage network.

Within B^2 Hub operates a pivotal role known as the Committer. This entity hashes the Batch data (specifically the Merkle root), stores the index, and submits it to the Bitcoin chain in inscription form. Accessing the data hash and storage index enables retrieval of complete data from the off-chain DA layer/storage layer. Assuming N nodes store Batch data under the chain, once a node is willing to share data with external entities, any interested party can access the required data. The trust assumption in this scenario is 1/N.

Certainly, it is evident that in the aforementioned process, B^2 Hub, tasked with validating Layer 2 state transitions, operates independently from the Bitcoin main network, serving solely as an off-chain verification layer. Consequently, the state verification scheme of Layer 2 at this juncture falls short of matching the reliability of the Bitcoin mainnet.

In general, ZK Rollup has the capability to fully inherit the security of Layer 1. However, given the current limitations of the Bitcoin chain in supporting only basic calculations and lacking direct ZK proof verification capabilities, no Layer 2 solution on Bitcoin can rival Ethereum’s security model, particularly those employing ZK Rollup techniques like Citrea and BOB.

Thus far, the more viable approach, as elucidated in the BitVM white paper, involves offloading complex computational processes from the Bitcoin chain. Only essential calculations are migrated to the chain when required. For instance, the computation traces generated during ZK proof verification can be publicly disclosed and shared with external entities for scrutiny. If any discrepancies arise in intricate calculation steps, individuals can verify these contentious calculations on the Bitcoin chain. This necessitates leveraging the Bitcoin scripting language to emulate the functionalities of specialized virtual machines such as the Ethereum Virtual Machine (EVM). While this endeavor may entail significant engineering efforts, it remains a feasible undertaking.

References:“A minimalist interpretation of BitVM: How to verify fraud proof on the BTC chain (execute the operation code of EVM or other VM)”

In B^2 Network’s technical solution, once the sequencer generates a new batch, it is transmitted to the aggregator and Prover. The Prover then ZK-izes the data verification process of the batch, produces a ZK certificate, and eventually transfers it to the EVM-compatible B^2 Hub node. The ZK Proof is authenticated through a Solidity contract, with all computational processes broken down into intricate low-level logic gate circuits. These circuits are encoded in the Bitcoin script language, formatted, and submitted to a third-party Data Availability (DA) platform with adequate throughput.

Should individuals question the disclosed ZK verification traces and suspect an error in a specific step, they have the option to issue a “challenge” on the Bitcoin chain. This challenge prompts the Bitcoin node to directly scrutinize the disputed step and mete out appropriate consequences if necessary.

(The overall structure diagram of B^2 Network, excluding data sampling nodes)

So who is punished? Actually it is Committer. Within the framework of B^2 Network, the Committer not only broadcasts the previously mentioned data hash to the Bitcoin chain but also discloses the verification “commitment” of the ZK certificate to the Bitcoin main network. Through specific configurations of Bitcoin Taproot, individuals retain the ability to raise queries and contest the “ZK Proof Verification Commitment” issued by the Committer on the Bitcoin chain at any given time.

To elaborate on the concept of “commitment,” it denotes individuals asserting the accuracy of certain off-chain data and publishing a corresponding statement on the blockchain. This statement serves as a “commitment” where promise values are linked to specific off-chain data. In the B^2 solution, if any party questions the ZK verification commitment issued by the Committer, they have the option to challenge it.

One might question why B^2 Hub needs to verify the ZK certificate “repeatedly and comprehensively” if it already validates the Batch upon receipt. Why not disclose the batch verification process publicly for direct challenges instead of introducing ZK proof? The inclusion of ZK proof serves to condense the calculation traces into a more manageable size before release. Publicly revealing the verification process involving Layer 2 transactions and state changes in logic gates and Bitcoin scripts would result in substantial data size. ZKization effectively compresses this data before dissemination.

Here is a concise summary of B^2’s workflow:

1. The sequencer in B^2 generates new Layer 2 blocks and consolidates multiple blocks into data batches. These batches are forwarded to the aggregator and Validator node in the B^2 Hub network.

2. The aggregator sends the data batch to the Prover node, enabling the creation of the corresponding zero-knowledge proof. Subsequently, the ZK certificate is transmitted to B^2’s DA and verifier network (B^2 Hub).

3. The B^2 Hub node verifies whether the ZK Proof from the aggregator aligns with the Batch from the Sequencer. Successful correspondence indicates verification passage. The verified Batch’s data hash and storage index are relayed to the Bitcoin chain by a designated B^2 Hub node (Committer).

4. The entire calculation process for verifying the ZK Proof is publicly disclosed by B^2 Hub, with the Commitment of this process submitted to the Bitcoin chain for potential challenges. A successful challenge results in economic penalties for the issuing B^2 Hub node (their UTXO on the Bitcoin chain is unlocked and transferred to the challenger).

This state verification approach of B^2 Network integrates ZK and fraud-proof methodologies, constituting a hybrid state verification method. With at least one honest node under the chain willing to challenge upon detecting an error, assurance is provided regarding the state transition integrity of B^2 Network.

According to insights from members of the Western Bitcoin community, there is speculation about a potential future fork of the Bitcoin mainnet to support enhanced computational capabilities. This could pave the way for direct ZK proof verification on the Bitcoin chain, heralding transformative changes for the entire Bitcoin Layer 2 landscape. Serving as a foundational DA and verification layer, B^2 Hub not only functions as a core component of B^2 Network but also empowers other Bitcoin second layers. In the competitive realm of Bitcoin Layer 2 solutions, off-chain functional expansion layers are gaining prominence, with B^2 Hub and BTCKB representing just a glimpse of this evolving landscape.

Disclaimer:

1. This article has been reproduced from [Geek Web3 ), with the original title “Analysis of the new B^2 technology roadmap: the necessity of DA and verification layer under the Bitcoin chain.” The copyright is attributed to the original author, Faust from Geek Web3. If there are any objections to the reprint, please contact the Gate Learn Team for prompt resolution following the relevant procedures.

2. The perspectives and opinions conveyed in this article solely reflect the author’s personal viewpoints and do not serve as investment advice.

3. Translations of the article into other languages are provided by the Gate Learn team. The translated articles may not be copied, disseminated, or plagiarized without mentioning Gate.io.