一文でわかるB^2新版技術ロードマップ：ビットコインのオフチェーンDAと検証レイヤーの必要性

執筆：Faust、ギーク web3

要約：

• B\^2 Network はビットコインチェーンの下に B\^2 Hub と呼ばれる DA レイヤーを設置し、この DA レイヤーネットワークは Celestia のアイデアを参考にして、データサンプリングとエラーレジスタを導入し、新しいデータが迅速に多数の外部ノードに配信されることを確保し、データの保持を極力避けるよう努めています。同時に、B\^2 Hub ネットワーク内の Committer は DA データのストレージインデックスとデータハッシュをビットコインチェーンにアップロードし、誰でも読み取れるようにします；
• DA レイヤーのノードの負担を軽減するために、B\^2 Hub の歴史データは永久に保存されないため、B\^2 は Arweave のようなストレージインセンティブ方式を通じて、より多くのノードがより完全な歴史データセットを保存するよう刺激するストレージネットワークの構築を試みています；
• 状態検証の面では、B\^2 はハイブリッドな検証スキームを採用し、オフチェーンで ZK 証明を検証し、オンチェーンでは bitVM のアイデアを通じて ZK 証明の検証の痕跡に挑戦します。1 つの挑戦者ノードがエラーを検出した後に挑戦を開始すれば、B\^2 ネットワークは安全であり、これは詐欺証明プロトコルの信頼モデルに合致しますが、ZK を使用しているため、この状態検証は実際にはハイブリッド型です。
• B\^2 Network の将来のロードマップに従い、EVM 互換の B\^2 Hub は複数のビットコイン Layer2 に接続するオフチェーン検証レイヤーおよび DA レイヤーとなり、BTCKB のようなビットコインのオフチェーン機能拡張レイヤーとなることができます。ビットコイン自体が多くのシナリオをサポートできないため、このオフチェーンで機能拡張レイヤーを構築する方法は、Layer2 エコシステムでますます一般的な現象になるでしょう。

B\^2 Hub：ビットコインのオフチェーンにおける汎用 DA レイヤーと検証レイヤー

現在のビットコインエコシステムは、機会と詐欺が共存するブルーオーシャンと言えます。この「刻印の夏」によって活気づいた新たな領域は、まさに肥沃な処女地であり、至る所にお金の香りが漂っています。今年の1月にビットコイン Layer2 が雨後の筍のように一斉に現れ、この元々荒れ果てた土地は瞬く間に無数の夢追い人の揺りかごとなりました。

しかし、最も本質的な問題に戻ると、Layer2 とは何か、人々は常に合意に達していないようです。サイドチェーンですか？インデクサーですか？橋を架けるチェーンが Layer2 と呼ばれるのですか？ビットコインとイーサリアムに依存する簡易プラグインは Layer と見なされるのでしょうか？これらの問題は、解決が難しい方程式のようで、常に明確な結論がありません。

イーサリアムと Celestia コミュニティの考え方に従えば、Layer2 はモジュール化されたブロックチェーンの特別なケースに過ぎず、この場合、「二層」と「一層」の間には密接な結合関係が存在し、二層ネットワークは Layer1 の安全性を大いに、または一定程度まで引き継ぐことができます。安全性という概念自体は、DA、状態検証、出金検証、検閲耐性、再編成耐性など、細分化された複数の指標に分解できます。

ビットコインネットワーク自体には多くの問題があり、完全な Layer2 ネットワークをサポートするには不利です。例えば、DA において、ビットコインのデータスループットはイーサリアムよりもはるかに低く、平均10分のブロック生成時間で計算すると、ビットコインの最大データスループットはわずか6.8KB/sで、イーサリアムの約1/20に過ぎません。このように混雑したブロックスペースは、高額なデータ発行コストを自然に生み出します。

（ビットコインブロック内のデータ発行コストは、1バイトあたり1.13ドルに達することもあります）

Layer2 が新しい取引データをビットコインブロックに直接発行すると、高スループットも低手数料も実現できません。したがって、データサイズを可能な限り小さく圧縮してからビットコインブロックにアップロードする必要があります。現在、Citrea はこの方法を採用しており、彼らは、一定期間内の状態変化量（state diff）、つまり複数のアカウントで発生した状態変更の結果と、対応する ZK 証明を一緒にビットコインチェーンにアップロードすると主張しています。

この場合、誰でもビットコインメインネットから state diff と ZKP をダウンロードし、その有効性を検証できますが、オンチェーンのデータサイズは軽量化できます。

（前 Polygon Hermez のホワイトペーパーには、上記の圧縮方法の原理が説明されています）

この方法はデータサイズを大幅に圧縮しますが、最終的にはボトルネックに直面することが容易です。例えば、10分間に数万件の取引が発生し、数万のアカウントが状態変更を受けたと仮定すると、最終的にはこれらのアカウントの変化を集約してビットコインチェーンにアップロードする必要があります。直接各取引データをアップロードするよりは軽量ですが、依然としてかなりのデータ発行コストが発生します。

そのため、多くのビットコイン Layer2 は DA データをビットコインメインネットにアップロードせず、Celestia などの第三者 DA レイヤーを直接利用しています。一方、B\^2 は別の方法を採用し、オフチェーンに DA ネットワーク（データ配信ネットワーク）を構築しました。これを B\^2 Hub と呼びます。 B\^2 のプロトコル設計では、取引データや state diff などの重要なデータはオフチェーンに保存され、ビットコインメインネットにはこれらのデータのストレージインデックスとデータハッシュ（実際にはメルクルルートで、説明の便宜上データハッシュと呼びます）だけがアップロードされます。

これらのデータハッシュとストレージインデックスは、刻印のような方法でビットコインチェーンに書き込まれ、ビットコインノードを運営する限り、データハッシュとストレージインデックスをローカルにダウンロードし、インデックス値に基づいて B\^2 のオフチェーン DA レイヤーまたはストレージレイヤーから元のデータを読み取ることができます。データハッシュに基づいて、オフチェーン DA レイヤーから取得したデータが正しいかどうか（ビットコインチェーン上のデータハッシュと一致するかどうか）を判断できます。このようなシンプルな方法により、Layer2 は DA 問題においてビットコインメインネットへの過度な依存を避け、手数料コストを節約し、高スループットを実現できます。

もちろん、無視できない点は、このようなオフチェーンの第三者 DA プラットフォームがデータ保持を行い、新しいデータを外部に取得させない可能性があることです。このシナリオには「データ保持攻撃」と呼ばれる専用の用語があり、データ配信における検閲耐性の問題に帰着されます。異なる DA スキームには異なる解決策がありますが、核心的な目的は、データを可能な限り迅速かつ広範に拡散させ、特権ノードの一部がデータ取得権を独占するのを防ぐことです。

B\^2 Network の公式な新しいロードマップに従い、その DA スキームは Celestia を参考にしています。後者の設計では、第三者のデータ提供者が Celestia ネットワークにデータを継続的に提供し、Celestia のブロック生成者がこれらのデータ片をメルクルツリーの形に組織し、TIA ブロックに詰め込み、ネットワーク内のバリデーター/フルノードにブロードキャストします。

これらのデータが多いため、ブロックが大きくなり、大多数の人がフルノードを運営できず、軽ノードを運営するしかありません。軽ノードは完全なブロックを同期せず、ブロックヘッダーのみを同期し、メルクルツリーのルートを記載します。

軽ノードはブロックヘッダーだけでは、メルクルツリーの全貌を知らず、新しいデータが何であるかを知らず、データに問題があるかどうかを検証できません。しかし、軽ノードはフルノードにツリー上の特定のリーフを要求できます。フルノードは要求に応じて、リーフと対応するメルクル証明を軽ノードに提出し、後者はこのリーフが確かに Celestia ブロックのメルクルツリーに存在することを確認できます。

（画像出典：W3 Hitchhiker）

Celestia ネットワークには多くの軽ノードが存在し、これらの軽ノードは異なるフルノードに対して高頻度のデータサンプリングを行い、メルクルツリー上のいくつかのデータ片をランダムに抽出します。軽ノードがこれらのデータ片を取得した後、接続できる他のノードに伝播させることができ、こうしてできるだけ多くの人/デバイスにデータを迅速に配信し、効率的なデータ伝播を実現します。十分な数のノードが迅速に最新のデータを取得できれば、人々は特定のデータ提供者を信頼する必要がなくなります。これは DA/データ配信の核心的な目的の一つです。

もちろん、上記の説明されたスキームだけでは攻撃シナリオが存在します。なぜなら、データ配信時に人々が迅速にデータを取得できることは保証されますが、データの生成元が悪意を持たないことは保証されません。例えば、Celestia のブロック生成者がブロックに少しのゴミデータを混ぜ込む可能性があり、人々がブロック内のすべてのデータ片を取得しても、「本来含まれるべき」完全なデータセットを復元できないのです（注意：「本来」という言葉は非常に重要です）。

さらに言えば、元のデータセットには100件の取引が含まれている可能性があり、その中のある取引のデータが外部に完全に伝播されていない場合、この時、1%のデータ片を隠すだけで、外部は完全なデータセットを解析できなくなります。これが最初のデータ保持攻撃問題で議論されたシナリオです。

実際、ここで説明されたシナリオを理解するためにデータの可用性を考えると、可用性という言葉はブロック内の取引データが完全であるか、利用可能であるか、他の人に直接検証させることができるかどうかを示すものであり、多くの人が理解するように、可用性がブロックチェーンの歴史データが外部に読み取られるかどうかを示すものではありません。したがって、Celestia の公式と L2BEAT の創設者は、データ可用性をデータ発行に改名すべきだと指摘しました。これは、ブロック内に完全な可用性の取引データセットが発行されたかどうかを意味します。

Celestia は二次元エラーレジスタを導入し、上記のデータ保持攻撃の問題を解決します。ブロック内に含まれる1/4のデータ片（エラーレジスタ）が有効であれば、人々は対応する元のデータセットを復元できます。ブロック生成者がブロック内に3/4のゴミデータ片を混ぜ込まない限り、外部は元のデータセットを復元できなくなりますが、この場合、ブロック内に含まれるゴミデータが多すぎて、軽ノードによって容易に検出されます。したがって、ブロック生成者にとっては、悪事を働かない方が良いでしょう。なぜなら、悪事はすぐに多くの人に気づかれるからです。

前述のスキームにより、「データ配信プラットフォーム」でデータ保持が発生するのを効果的に防ぐことができ、B\^2 Network は今後、Celestia のデータサンプリングを重要な参考として、KZG コミットメントなどの暗号技術を組み合わせて、軽ノードがデータサンプリングと検証を実行するコストをさらに削減することを目指します。データサンプリングを実行するノードが十分に多ければ、DA データの配信が効果的かつ信頼を必要としないものになります。

もちろん、上記のスキームは DA プラットフォーム自身のデータ保持問題を解決するだけですが、Layer2 の基盤構造には、データ保持を引き起こす能力を持つのは DA プラットフォームだけではなく、ソートノード（Sequencer）もあります。 B\^2 Network やほとんどの Layer2 のワークフローでは、新しいデータはソートノード Sequencer によって生成され、ユーザーから送信された取引を集約処理し、これらの取引の実行後の状態変更結果を添付してバッチ（batch）にパッケージ化し、DA レイヤーとして機能する B\^2 Hub ノードに送信します。

もしソートノードが最初に生成したバッチに問題があれば、データ保持の可能性が残りますが、もちろん他の形式の悪事のシナリオも含まれます。したがって、B\^2 の DA ネットワーク（B\^2 Hub）は、ソートノードが生成したバッチを受け取った後、まずバッチの内容を検証し、問題があれば拒否します。言い換えれば、B\^2 Hub は Celestia の DA レイヤーとして機能するだけでなく、オフチェーンの検証レイヤーとしても機能し、CKB が RGB++ プロトコルで果たす役割に似ています。

（不完全な B\^2 Network の基盤構造図）

B\^2 Network の最新の技術ロードマップによれば、B\^2 Hub はバッチを受け取り検証した後、一定期間のみ保持し、そのウィンドウ期間を過ぎると、バッチデータは期限切れとなり、B\^2 Hub ノードから削除されます。EIP-4844 のようなデータの淘汰および喪失問題を解決するために、B\^2 Network は一連のストレージノードを設定しました。これらのストレージノードはバッチデータを永続的に保存する責任を負い、これにより、誰でもいつでもストレージネットワーク内で必要な歴史データを検索できるようになります。

ただし、誰も無償で B\^2 ストレージノードを運営することはありません。より多くの人々にストレージノードを運営させ、ネットワークの信頼性を高めるためには、インセンティブメカニズムを提供する必要があります。インセンティブメカニズムを提供するためには、まず不正防止策を考える必要があります。例えば、もしあなたがインセンティブメカニズムを提案し、誰でも自分のデバイスにデータを保存すれば報酬を得られるとした場合、データをダウンロードした後に一部のデータを密かに削除し、自分が保存したデータが完全であると主張する人がいるかもしれません。これが最も一般的な不正行為の方法です。

Filecoin は PoRep と PoSt と呼ばれる証明プロトコルを通じて、ストレージノードが外部にストレージ証明を示し、指定された期間内に確かにデータを完全に保存していることを証明します。しかし、このストレージ証明スキームは ZK 証明を生成する必要があり、計算の複雑さが非常に高く、ストレージノードのハードウェアに高い要求を課すため、経済的コストの面で実行可能な方法ではないかもしれません。

B\^2 Network の新しい技術ロードマップでは、ストレージノードは Arweave に似たメカニズムを採用し、ブロック権を争奪してトークンインセンティブを得る必要があります。もしストレージノードが私的にデータの一部を削除した場合、次のブロック生成者になる確率が低下し、データを最も多く保持しているノードが成功してブロックを生成し、より多くの報酬を得る可能性が高くなります。したがって、大多数のストレージノードにとっては、完全な歴史データセットを保持する方が良いでしょう。

もちろん、インセンティブがあるのはストレージノードだけではなく、前述の B\^2 Hub ノードも含まれます。ロードマップによれば、B\^2 Hub は Permissionless の POS ネットワークを構築し、誰でも十分なトークンをステーキングすれば B\^2 Hub またはストレージネットワークの一員になれるようにします。この方法で、B\^2 Network はオフチェーンで分散型の DA プラットフォームとストレージプラットフォームを構築し、将来的には B\^2 以外のビットコイン Layer2 を統合し、汎用のビットコインオフチェーン DA レイヤーとデータストレージレイヤーを構築しようとしています。

ZK と詐欺証明を混用した状態検証スキーム

前述のように、B\^2 Network の DA ソリューションを説明しましたが、次にその状態検証スキームについて重点的に説明します。状態検証スキームとは、Layer2 がどのように自らの状態変化を十分に「信頼を必要としない」ものとして保証するかを指します。

（L2BEAT ウェブサイトが Scroll に対して評価した5つの安全指標のうち、State Validation は状態検証スキームを指します）

前述のように、B\^2 Network やほとんどの Layer2 のワークフローでは、新しいデータはソートノード Sequencer によって生成され、ユーザーから送信された取引を集約処理し、これらの取引の実行後の状態変更結果を添付してバッチ（batch）にパッケージ化し、Layer2 ネットワーク内の他のノード、通常の Layer2 フルノードや B\^2 Hub ノードに送信されます。

B\^2 Hub ノードはバッチデータを受け取った後、その内容を解析し検証を行います。ここには前述の「状態検証」が含まれます。実際、状態検証とは、ソートノードが生成したバッチに記録された「取引実行後の状態変化」が正しいかどうかを検証することです。B\^2 Hub ノードがエラー状態を含むバッチを受け取った場合、それを拒否します。

実際、B\^2 Hub は本質的に POS 公共チェーンであり、ブロック生成者と検証者の区別があります。一定の時間ごとに、B\^2 Hub のブロック生成者は新しいブロックを生成し、他のノード（検証者）に伝播します。これらのブロックにはソートノードが提出したバッチデータが含まれています。残りのワークフローは前述の Celestia に似ており、多くの外部ノードが頻繁に B\^2 Hub ノードにデータ片を要求し、このプロセスでバッチデータが多くのノードデバイスに配信され、前述のストレージネットワークも含まれます。

B\^2 Hub には Committer（コミッター）と呼ばれる可輪換の役割が存在し、バッチのデータハッシュ（実際にはメルクルルート）とストレージインデックスを刻印の形式でビットコインチェーンに提出します。このデータハッシュとストレージインデックスを読み取る限り、オフチェーンの DA レイヤー/ストレージレイヤーから完全なデータを取得する方法があります。オフチェーンに N 個のノードがバッチデータを保存していると仮定すると、そのうちの 1 つのノードが外部にデータを提供する意志があれば、誰でも必要なデータを取得できます。ここでの信頼仮定は 1/N です。

もちろん、上記のプロセスでは、Layer2 の状態変化の有効性を検証する責任を持つ B\^2 Hub はビットコインメインネットから独立しており、単なるオフチェーンの検証レイヤーです。したがって、この時点で Layer2 の状態検証スキームは、信頼性の面でビットコインメインネットと同等ではありません。

一般的に、ZK Rollup は Layer1 の安全性を完全に引き継ぐことができますが、現在ビットコインチェーン上では非常に単純な計算しかサポートされておらず、ZK 証明を直接検証することができないため、どの Layer2 も安全モデルの面でイーサリアムの ZK Rollup と同等にはなっていません。Citrea や BOB なども含まれます。

現時点で「比較的実行可能な」考え方は、BitVM のホワイトペーパーで述べられているように、複雑な計算プロセスをビットコインチェーンの下に移し、必要な場合にのみ一部の単純な計算をオンチェーンで行うことです。例えば、ZK 証明の検証時に生成される計算の痕跡を公開し、外部にチェックさせることができます。もし人々がその中のある微細な計算ステップに問題があると発見すれば、ビットコインチェーン上で「論争のある計算」を検証できます。ここでは、ビットコインのスクリプト言語を使用して、EVM などの特殊な仮想マシンの機能をシミュレートする必要があり、消費される工数は非常に大きいかもしれませんが、不可能ではありません。

B\^2 Network の技術スキームでは、ソートノードが新しいバッチを生成した後、アグリゲーターおよびプローバーに転送され、後者はバッチのデータ検証プロセスを ZK 化し、ZK 証明を生成し、最終的に B\^2 Hub ノードに転送します。B\^Hub ノードは EVM 互換であり、Solidity コントラクトを通じて ZK 証明を検証します。この中で関与するすべての計算プロセスは、非常に低レベルの論理ゲート回路の形に分解され、これらの論理ゲート回路はビットコインスクリプト言語の形式で表現され、スループットが十分に大きい第三者 DA プラットフォームにすべて提出されます。

もし人々がこれらの公開された ZK 検証の痕跡に疑問を持ち、ある小さなステップに誤りがあると感じた場合、ビットコインチェーン上で「挑戦」を行い、ビットコインノードに直接この問題のあるステップをチェックさせ、適切な罰を与えることができます。

（B\^2 Network の全体構造図、データサンプリングノードを含まない）

では、誰が罰せられるのでしょうか？実際にはコミッターです。B\^2 Network の設定では、コミッターは前述のデータハッシュをビットコインチェーンに公開するだけでなく、ZK 証明の検証「コミットメント」をビットコインメインネットに公開する必要があります。ビットコイン Taproot のいくつかの設定を通じて、あなたはいつでもビットコインチェーン上でコミッターが公開した「ZK 証明検証コミットメント」に疑問を持ち、挑戦することができます。

ここで「コミットメント」とは何かを説明します。「コミットメント」とは、ある人々が特定のオフチェーンデータが正確であると主張し、それに対応する声明をチェーン上に公開することを意味します。この声明が「コミットメント」です。コミットメント値は特定のオフチェーンデータにバインドされます。B\^2 のスキームでは、もし誰かがコミッターが公開した ZK 検証コミットメントに問題があると考えた場合、挑戦することができます。

前述のように、B\^2 Hub はバッチを受け取った後、その有効性を直接検証すると言いましたが、ここでなぜ「再度」ZK 証明を検証する必要があるのでしょうか？なぜバッチの検証プロセスを直接公開して人々に挑戦させるのではなく、ZK 証明を導入する必要があるのでしょうか？これは、計算の痕跡を十分に小さく圧縮するためです。もし直接 Layer2 の取引を検証し、状態変化を生成する計算プロセスを論理ゲート回路やビットコインスクリプトの形式で公開すると、非常に大きなデータサイズが発生します。ZK 化することで、データサイズを大幅に圧縮してから公開できます。

ここで B\^2 のワークフローを大まかにまとめます：

1. B\^2 のソートノード Sequencer は新しい Layer2 ブロックを生成し、複数のブロックをデータバッチ（data batch）に統合します。データバッチはアグリゲーター Aggregator と B\^Hub ネットワーク内のバリデータノードに送信されます。
2. アグリゲーターはデータバッチをプローバーノードに送信し、後者が対応するゼロ知識証明を生成します。ZK 証明はその後、B\^2 の DA および検証者ネットワーク（B\^2Hub）に送信されます。
3. B\^2Hub ノードはアグリゲーターから送信された ZK 証明がソートノードから送信されたバッチと一致するかどうかを検証します。両者が一致すれば、検証を通過します。検証を通過したバッチのデータハッシュとストレージインデックスは、特定の B\^Hub ノード（コミッターと呼ばれる）によってビットコインチェーンに送信されます。
4. B\^Hub ノードはその検証 ZK 証明の計算プロセス全体を公開し、計算プロセスのコミットメントをビットコインチェーンに送信し、誰でもそれに挑戦できるようにします。挑戦が成功した場合、コミットメントを公開した B\^Hub ノードは経済的な罰を受けます（それがビットコインチェーン上の UTXO が解除され、挑戦者に転送されます）。

B\^2 Network のこの状態検証スキームは、ZK を導入し、詐欺証明を採用しており、実際にはハイブリッド型の状態検証方式です。オフチェーンに少なくとも 1 つの誠実なノードが存在し、エラーを検出した後に挑戦する意志があれば、B\^2 Network の状態変化に問題がないことが保証されます。

西洋のビットコインコミュニティのメンバーの見解によれば、将来的にビットコインメインネットは適切なフォークを行い、より多くの計算機能をサポートする可能性があります。おそらく将来的には、ビットコインチェーン上で ZK 証明を直接検証することが現実となり、その際にはビットコイン Layer2 全体に新しいパラダイムシフトをもたらすでしょう。そして、B\^2 Hub は汎用の DA レイヤーおよび検証レイヤーとして、B\^2 Network の専用モジュールとして機能するだけでなく、他のビットコイン Layer2 にも力を与えることができます。ビットコイン Layer2 の激しい競争の中で、オフチェーン機能拡張レイヤーはますます重要になり、B\^Hub と BTCKB の出現は、これらの機能拡張レイヤーの氷山の一角に過ぎないかもしれません。