B^2新バージョンの技術ロードマップの分析:ビットコインのためのオフチェーンDAと検証レイヤーの必要性

初級編3/24/2024, 6:46:02 PM
B^2 Networkは、オフチェーンのDAネットワークを使用してデータの圧縮と検証の問題に対処する分散型データ可用性(DA)およびストレージプラットフォームです。これは、ビットコインのメインネットワークへの依存を減らすことを目的としています。B^2 Hubは、Celestiaと同様にDAレイヤーおよびオフチェーン検証レイヤーとして機能し、データの差し控えやその他の悪意のあるアクティビティを防ぎます。将来的には、B ^ 2ネットワークはビットコインレイヤー2を組み込んで、ビットコインエコシステム内にユニバーサルDAレイヤーとデータストレージレイヤーを確立する予定です。B^2ハブ・ノードはトランザクション・バッチを検証し、ストレージ・ノードはブロック・プロダクション権限を競い合ってインセンティブを獲得します。B^2ネットワークのワークフローには、シーケンサーが新しいブロックを作成し、アグリゲーターがZKプルーフ生成のためにそれらをProverに送信し、B^2ハブノードがデータハッシュを検証してビットコインチェーンに送信することが含まれます。ユニバーサルDAおよび検証レイヤーとして、B ^ 2ハブは他のビットコインセカンドレイヤーソリューションを強化する可能性があります。

概要:

B^2 Networkは、Celestiaの概念からインスピレーションを得て、ビットコインチェーン内にB^2 Hubとして知られるデータ可用性(DA)レイヤーを設立しました。このDAレイヤーネットワークは、新しいデータを多数の外部ノードに迅速に配布し、データの保留を防ぐためにデータサンプリングと消去符号化を実装しています。さらに、B^2 Hubネットワーク内のコミッターは、DAデータのストレージインデックスとデータハッシュをビットコインチェーンに公開アクセスするためにアップロードする責任があります。

DAレイヤーノードの負担を軽減するために、B^2 Hubの歴史データは永続的に保持されません。その結果、B^2は、Arweaveに似たストレージインセンティブメカニズムを採用して、より多くのノードが包括的な歴史データセットを保存するためのストレージ報酬を受け取ることを促進しようと努力しています;

・ステータス検証に関して、B^2はZKプルーフをオフチェーンで検証し、bitVMコンセプトを活用してZKプルーフ検証トレースに挑戦するハイブリッド検証手法を採用しています。不正検証プロトコルの信頼モデルに合致するよう、チャレンジャーノードがエラーを検知した際にチャレンジを開始し、B^2ネットワークの安全性を確保しています。ただし、ZKプルーフを利用しているため、このステータス検証プロセスは本質的にハイブリッドな性質を持っています;

B^2 Networkの将来のロードマップに沿って、EVM互換のB^2 Hubは、複数のBitcoin Layer 2ソリューションを接続するオフチェーン検証レイヤーおよびDAレイヤーとして機能する可能性があります。BTCKBに類似したBitcoinオフチェーン機能拡張レイヤーに進化することを目指しています。Bitcoinがさまざまなシナリオをサポートする上での制約を考慮すると、オフチェーン機能拡張レイヤーの開発がLayer 2エコシステム内で一般的な実践となることが予想されています。

B^2 Hub: ビットコインチェーン内の汎用データ可用性(DA)レイヤーおよび検証レイヤー

現在のBitcoinエコシステムは、機会とリスクの広がりを思わせるものであり、碑文の夏の余韻がこの領域に新たな息吹をもたらし、豊かな未開の土地のように富の香りが漂う状態となっています。今年の初めに登場したBitcoin Layer 2の出現により、このかつての荒涼とした風景は、多くのビジョナリーにとっての憧れの中心地に変貌しました。

問題の核心に戻ります: Layer 2の定義は個々の間で論点となっています。サイドチェーンですか?インデクサーですか?Layer 2という用語は接続を確立するチェーンを含みますか?単なるBitcoinとEthereumに依存するプラグインはLayerとして資格がありますか?これらの問いは、明確な解決策のない未解決の方程式に似ています。

イーサリアムおよびセレスティアコミュニティの視点によると、Layer 2はモジュラーブロックチェーンの明確なインスタンスを表しています。この文脈では、“第2レイヤー”と“第1レイヤー”との間に密接な相互依存関係が存在します。第1レイヤーのセキュリティは、第2レイヤーネットワークに部分的または大幅に受け継がれる可能性があります。セキュリティ自体には、DA、ステータス検証、引き出し検証、検閲耐性、再編成耐性などのさまざまなサブカテゴリが含まれます。

ビットコインネットワークの固有の制限を考慮すると、包括的なLayer 2ネットワークの支援には適していません。例えば、DAの観点から見ると、ビットコインのデータ処理能力は明らかにイーサリアムを大きく下回っています。平均ブロック生成時間が10分のため、ビットコインの最大データ処理速度はわずか6.8KB/sであり、イーサリアムの能力の約1/20です。そのため、混雑したブロックスペースによってデータの公開コストが高騰しています。

(ビットコインブロックにデータを公開するコストは、KBあたり$5に達することさえあります)

Layer 2が新しく追加されたトランザクションデータをBitcoinブロックに直接公開すると、高いスループットや低い取引手数料を実現できません。これを解決するための1つのアプローチは、Bitcoinブロックにアップロードする前にデータを大幅に圧縮することです。Citreaは現在、この方法を採用しており、複数のアカウント間で発生する状態変更(ステートディフ)を特定の期間にわたってBitcoinチェーンにアップロードし、対応するZK証明書とともに伴います。

これにより、誰でもビットコインメインネットワークからダウンロードした状態の差分とZKPの妥当性を検証できるようになりますが、チェーン上の軽量データを維持します。

(元のPolygon Hermezホワイトペーパーには、上記の圧縮スキームの原理が説明されています)

この方法によって達成された重要なデータサイズの圧縮にもかかわらず、多くの取引が短期間に多くのアカウントの状態変化を引き起こすシナリオでは、ボトルネックに直面する可能性があります。個々の取引データを直接アップロードするよりも軽量ですが、アカウントの変更をアップロードすることには相当なデータ公開コストがかかります。

その結果、多くのBitcoin Layer 2ソリューションは、DAデータをBitcoinメインネットワークにアップロードせず、CelestiaのようなサードパーティのDAレイヤーを利用することを選択しています。一方で、B^2は異なるアプローチを採用し、B^2ハブとして知られるチェーン直下のData Availability(DA)ネットワークを確立しています。この設計では、トランザクションデータやステートの差分などの重要なデータはオフチェーンに保存され、そのストレージインデックスとデータハッシュ(簡単のためにデータと呼ばれる)のみがBitcoinメインネットにアップロードされます。

これらのデータハッシュとストレージインデックスは、刻印と同様に、ビットコインチェーン上に記録されています。ビットコインノードを実行することで、個人はデータハッシュとストレージインデックスにローカルでアクセスすることができます。インデックス値を使用して、オフチェーンDAまたはストレージレイヤーから元のデータを取得できます。データハッシュにより、ビットコインチェーン上の対応するハッシュに対してオフチェーンDAレイヤーから取得したデータの正確性を検証できます。この直感的なアプローチにより、Layer 2ソリューションはDAの問題に対するビットコインメインネットへの依存を緩和し、取引コストを削減し、高いスループットを実現できます。

ただし、重要なのは、チェーン内のサードパーティDAプラットフォームがデータの保留プラクティスに従事する可能性があることを認識することです。これにより、新しいデータへの外部アクセスが阻害され、選択されたノードがデータアクセス権を制御するという現象、すなわち「データ保留攻撃」として知られる現象が発生する可能性があります。さまざまなDAソリューションがこの問題に異なる方法で対処しており、共通の目標はデータを迅速かつ広範囲に普及させ、一部のノードがデータアクセス権を制御するのを防ぐことです。

B^2ネットワークの公式新しいロードマップによると、そのDAソリューションはCelestiaを活用しています。後者の設計では、サードパーティのデータプロバイダが継続的にデータをCelestiaネットワークに提供します。Celestiaのブロック生産者はこれらのデータ断片をMerkle Treeの形式で整理し、それらをTIAブロックに詰め込んでネットワークにブロードキャストします。バリデータ/フルノード。

データが多く、ブロックが比較的大きいため、ほとんどの人がフルノードを実行する余裕がなく、軽量ノードのみを実行できます。軽量ノードは完全なブロックを同期しないが、その上に書かれたMerkle Treeのルートを持つブロックヘッダーのみを同期します。

B^2 Networkの最新のロードマップによると、そのDAソリューションはCelestiaからインスピレーションを得ています。この設計では、外部データプロバイダーが継続的にデータをCelestiaネットワークに供給します。Celestia内のブロック製造業者は、これらのデータ断片をMerkle Tree構造に整理し、それらをTIAブロックに埋め込み、ネットワークの検証者とフルノードに伝達します。データの量が膨大でブロックサイズが大きいため、多くの個人はフルノードの代わりに軽量ノードを実行することを選択しています。軽量ノードはMerkle Treeルートを含むブロックヘッダーのみを同期化します。

ライトノードはMerkle Treeの包括的なビューを欠いており、新しいデータコンテンツを検証することはできませんが、特定のリーフノードをフルノードにリクエストすることができます。フルノードは、リクエストされたリーフノードと対応するMerkle Proofsを提供して、セレスティアブロックのMerkle Tree内に存在することをライトノードに納得させ、それが偽造されたデータでないことを保証します。

(画像の出典:W3ヒッチハイカー)

Celestiaネットワークには、さまざまなフルノードから高頻度のデータサンプリングを行う多数のライトノードが存在します。これらのライトノードは、Merkle Treeから特定のデータ断片をランダムに選択し、それを他の接続されたノードに迅速かつ効率的に拡散させます。これにより、データを広範な人々やデバイスに配信することを目指しています。このアプローチにより、十分な数のノードが迅速に最新のデータを受け取ることができ、限られたデータプロバイダのグループに依存する必要がなくなります。この基本的な目標は、Data Availability(DA)とデータ配信の中核的な本質を強調しています。

ただし、前述の解決策が迅速なデータアクセスを可能にする効果的であるにもかかわらず、データソースの整合性を保証するものではありません。例えば、Celestiaのブロック生産者がブロックに誤ったデータを挿入する可能性があり、完全で正確なデータセットを再構築する取り組みを複雑化させることがあります。ブロック内のすべてのデータ断片を取得しても、それらを含めるべき完全なデータセットを復元することはできません(注:ここで「すべき」という言葉は重要です)。

さらに、特定の取引データが外部の当事者に開示されないシナリオでは、データ断片のわずか1%を保留することが、外部の者が全データセットを再構築するのを妨げる可能性があります。これはデータ保留攻撃の状況に似ています。

上述の文脈において、データの入手可能性の理解は、ブロック内の取引データが完全であり、アクセス可能であり、検証目的で容易に共有可能であるかどうかに関連しています。一般的な認識とは異なり、入手可能性は外部エンティティに対するブロックチェーンの歴史的データのアクセス可能性だけを示すものではありません。そのため、Celestiaの関係者やL2BEATの創設者は、データの入手可能性を「データのリリース」と改名することを提唱し、ブロック内の包括的でアクセス可能な取引データセットの公開を意味しています。

データの隠蔽攻撃の問題に対処するために、Celestiaは二次元の消去符号化を採用しています。ブロック内のデータフラグメント(消去符号)の少なくとも1/4が有効であれば、個人は元のデータセットを再構築することができます。しかし、ブロックプロデューサーが3/4の誤ったデータフラグメントを挿入した場合、データセットの再構築は実現不可能となります。特に、ブロック内のジャンクデータの過剰な存在は、軽量ノードによって容易に特定され、ブロックプロデューサーによる悪意のある活動に対する抑止となります。

このソリューションを実装することで、Celestiaはデータ配信プラットフォームにおけるデータの隠蔽を効果的に軽減します。B^2 Networkは、将来的にCelestiaのデータサンプリング手法を基本的な参照点として活用し、KZGコミットメントなどの暗号技術を統合する可能性があります。これにより、軽量ノードによって実施されるデータサンプリングおよび検証プロセスの効率と信頼性が向上します。

前述の解決策がDAプラットフォーム自体内のデータ保持に対処している一方で、レイヤー2のインフラストラクチャでは、DAプラットフォームとシーケンサーの両方がデータ保持能力を持っています。B^2 Networkのようなワークフローでは、シーケンサーはユーザートランザクションとその結果の状態変更を整理して処理し、それらをDAレイヤーとして機能するB^2 Hubノードに送信する前に新しいデータを生成します。

シーケンサーによって生成されたバッチ内で異常が発生した場合、データの隠蔽やその他の悪意のある活動のリスクがあります。そのため、B^2 HubのDAネットワークは、バッチを受け取るとその内容を細心の注意をもって検証し、問題のあるバッチを拒否します。したがって、B^2 HubはCelestiaに類似したDAレイヤーとして機能するだけでなく、RGB++プロトコルにおけるCKBと同様のオフチェーン検証レイヤーとしても機能しています。

(不完全な B^2 ネットワーク基本構造図)

B^2 Networkの最新テクノロジーロードマップに従い、B^2 Hubがバッチを受信し検証すると、一定期間バッチを保持してからローカルノードから期限切れになり削除されます。EIP-4844と同様のデータの陳腐化と損失の懸念に対処するために、B^2 Networkはバッチデータを永久に保存するストレージノードのネットワークを構築し、必要なときに歴史データを簡単に取得できるようにしています。

ただし、個人が強い理由がない限り、B^2ストレージノードを運用する可能性は低いです。 より多くの参加者にストレージノードを実行させ、ネットワークの信頼性を向上させるためには、インセンティブメカニズムを確立する必要があります。 そのようなメカニズムを実装するには、不正行為を防止するための措置が必要です。 たとえば、インセンティブシステムがデータをローカルデバイスに保存する個人を報酬する場合、データの一部をダウンロード後に削除し、自分の保存されたデータが完全であると虚偽の主張をするという不正行為のリスクがあります。—これは非常に一般的な詐欺の形態です。

Filecoinは、PoRepおよびPoStとして知られるプルーフプロトコルを採用しており、ストレージノードが指定された時間枠内でデータを安全に格納したことを証明する証明としてストレージ証明書を提供できるようにしています。ただし、このストレージ証明のアプローチにはZKプルーフの生成が関与しており、計算上の負荷が高く、ストレージノードに重要なハードウェア要件を課す可能性があり、経済的に実現不可能になる可能性があります。

B^2 Networkの最新の技術ロードマップでは、ストレージノードはArweaveに似たメカニズムを実装し、トークンインセンティブを獲得するためにブロックを生成する機会を競い合います。ストレージノードがデータを隠れて削除した場合、次のブロックプロデューサーになる可能性が低くなります。最も多くのデータを保持しているノードが、ブロックを成功製造し、より大きな報酬を受け取る可能性が高くなります。したがって、ほとんどのストレージノードにとって、完全な履歴データセットを維持することは、ブロック生産の見通しを最適化する上で有利です。

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

以前、B^2ネットワークのデータ可用性(DA)ソリューションについて詳細に説明しましたが、今度はその状態検証メカニズムについて詳しく説明します。 「状態検証スキーム」という用語は、レイヤー2が十分に「信頼できる」状態遷移をどのように確保するかに関連しています。

(L2BEATウェブサイトは、Scrollの5つの主要なセキュリティ指標を評価します。State Validationは状態検証スキームを指します)

Scrollのセキュリティ指標を評価するL2BEATのWebサイトで強調されているように、State Validationは特に状態検証スキームに対応しています。B^2 ネットワークおよびレイヤ 2 プロセスの大部分では、新しいデータはシーケンサによって発信されます。このエンティティは、ユーザーが開始したトランザクションと、その結果として生じる実行後のステータス変更を統合して処理します。これらの変更はバッチにバンドルされ、標準のレイヤー 2 フル ノードと B^2 ハブ ノードを含むレイヤー 2 ネットワーク内のさまざまなノードに配布されます。

バッチデータの受信後、B^2 Hubノードは細心の注意を払ってその内容を解析し、以前に言及された「状態の検証」を含む。基本的に、状態の検証は、シーケンサーが生成したバッチに記録された「取引実行後の状態変化の妥当性」を検証することを意味する。バッチ内の誤った状態は、B^2 Hubノードによって拒否される。

Proof-of-Stake(POS)パブリックチェーンとして機能するB^2 Hubは、ブロックプロデューサーと検証者を区別します。 定期的に、B^2 Hubのブロックプロデューサーは新しいブロックを生成し、それを他のノード(バリデータ)に伝播します。 これらのブロックには、シーケンサーによって提出されたバッチデータが含まれ、Celestiaに似たプロセスを反映しています。 外部ノードは頻繁にB^2 Hubノードからデータ断片をリクエストし、前述のストレージネットワークを含む多数のノードデバイスにバッチデータを配布することを容易にします。

B^2 Hub内には、コミッターとして知られる重要な役割があります。このエンティティは、バッチデータ(特にMerkleルート)をハッシュ化し、インデックスを保存し、それをビットコインチェーンに銘文形式で提出します。データハッシュとストレージインデックスにアクセスすることで、オフチェーンのDAレイヤー/ストレージレイヤーから完全なデータを取得できます。チェーンの下にN個のノードがバッチデータを保存していると仮定すると、ノードが外部エンティティとデータを共有する意思を持つと、関心を持つ任意の当事者が必要なデータにアクセスできます。このシナリオでの信頼の前提は1/Nです。

確かに、前述のプロセスでは、Layer 2の状態遷移を検証するB^2 Hubが、Bitcoinメインネットワークとは独立して動作し、純粋にオフチェーンの検証レイヤーとして機能しています。その結果、この時点でのLayer 2の状態検証スキームは、Bitcoinメインネットの信頼性には及びません。

一般的に、ZKロールアップはレイヤー1のセキュリティを完全に受け継ぐ能力を持っています。しかし、現在のビットコインチェーンの制約を考慮すると、基本的な計算のみをサポートし、直接的なZK証明検証機能がないことから、Bitcoin上のレイヤー2ソリューションは、特にCitreaやBOBなどのZKロールアップ技術を採用しているものは、Ethereumのセキュリティモデルには匹敵しないでしょう。

これまで、BitVMホワイトペーパーで詳しく説明されているように、ビットコインチェーンから複雑な計算プロセスを外部に移すことが、より実現可能なアプローチです。必要に応じて、必要最小限の計算のみがチェーンに移行されます。たとえば、ZKプルーフ検証中に生成された計算トレースは、公開され、外部機関と共有される可能性があります。複雑な計算ステップで何か矛盾が発生した場合、個人はこれらの論争のある計算をビットコインチェーンで検証できます。これには、ビットコインスクリプト言語を活用して、イーサリアム仮想マシン(EVM)などの専門仮想マシンの機能をエミュレートする必要があります。この取り組みにはかなりの技術努力が必要かもしれませんが、それでも実現可能な取り組みです。

参考文献:"BitVMのミニマリスト的な解釈:BTCチェーン上で不正証明を検証する方法(EVMまたは他のVMの操作コードを実行する)"

B^2 Networkの技術ソリューションでは、シーケンサーが新しいバッチを生成すると、それが集約者とプルーバに送信されます。その後、プルーバはバッチのデータ検証プロセスをZK-izeし、ZK証明書を生成し、最終的にEVM互換のB^2 Hubノードに転送します。ZKプルーフはSolidity契約を介して認証され、すべての計算プロセスは複雑な低レベルの論理ゲート回路に分解されます。これらの回路はBitcoinスクリプト言語でエンコードされ、フォーマットされ、適切なスループットを持つサードパーティのデータ可用性(DA)プラットフォームに提出されます。

個人が開示されたZK検証トレースを疑問視し、特定のステップでエラーが発生していると疑う場合、ビットコインチェーン上で「チャレンジ」を発行するオプションがあります。このチャレンジにより、ビットコインノードは直接争われたステップを精査し、必要に応じて適切な結果を出します。

(データサンプリングノードを除くB^2ネットワークの全体構造図)

では、誰が罰せられるのでしょうか? 実際に罰せられるのはCommiterです。B^2 Networkの枠組みの中で、Commiterは以前に言及されたデータハッシュをビットコインチェーンにブロードキャストするだけでなく、ZK証明書の検証「コミットメント」をビットコインメインネットワークに開示します。Bitcoin Taprootの特定の構成を通じて、個人はいつでもビットコインチェーン上でCommiterによって発行された「ZKプルーフ検証コミットメント」に疑問を提起し、異議を申し立てる能力を保持します。

「コミットメント」という概念を詳しく説明すると、個人がオフチェーンデータの正確性を主張し、それに対応する声明をブロックチェーンに公開することを指します。この声明は「コミットメント」として機能し、約束の値が特定のオフチェーンデータにリンクされています。B^2ソリューションでは、コミッターによって発行されたZK検証コミットメントに疑問を持つ当事者がいる場合、それに異議を唱える権利があります。

B^2 Hubが受信時にバッチを検証済みである場合、なぜZK証明書を「繰り返し詳細に」検証する必要があるのか疑問に思うかもしれません。なぜZKプルーフを導入する代わりに、直接的な挑戦のためにバッチ検証プロセスを公開しないのでしょうか? ZKプルーフの含有は、リリース前に計算トレースをより管理しやすいサイズに縮小するためのものです。Layer 2トランザクションと状態変化、ロジックゲート、ビットコインスクリプトに関する検証プロセスを公開すると、膨大なデータサイズが発生します。ZK化によって、このデータを効果的に圧縮してから配信します。

B^2のワークフローの簡潔な要約をご紹介します:

  1. B^2のシーケンサーは、新しいレイヤー2ブロックを生成し、複数のブロックをデータバッチにまとめます。これらのバッチは、B^2 Hubネットワーク内のアグリゲーターおよびバリデーターノードに転送されます。

  2. アグリゲータは、データバッチをProverノードに送信し、対応するゼロ知識証明の作成を可能にします。その後、ZK証明書がB^2のDAおよび検証ネットワーク(B^2 Hub)に送信されます。

  3. B^2 Hubノードは、アグリゲータからのZKプルーフがシーケンサーからのバッチと一致するかを検証します。成功した対応は検証通過を示します。検証されたバッチのデータハッシュとストレージインデックスは指定されたB^2 Hubノード(コミッター)によってビットコインチェーンに中継されます。

  4. ZKプルーフを検証するための計算プロセス全体は、B^2 Hubによって公開され、このプロセスのコミットメントは潜在的な挑戦のためにビットコインチェーンに提出されます。 成功した挑戦は、発行B^2 Hubノードに経済的ペナルティをもたらします(彼らのビットコインチェーン上のUTXOがアンロックされ、チャレンジャーに転送されます)。

B^2 Networkのこの状態検証アプローチは、ZKと詐欺証明の手法を統合し、ハイブリッド状態検証方法を構成しています。少なくとも1つの正直なノードがエラーを検出した場合にチャレンジすることを望んでいるチェーンによって、B^2 Networkの状態遷移の整合性に関する保証が提供されます。

西部ビットコインコミュニティのメンバーからの情報によると、ビットコインメインネットの将来のフォークに関する憶測があり、拡張された計算能力をサポートすることが検討されています。これにより、ビットコインチェーン上での直接ZKプルーフ検証が可能になり、ビットコインLayer 2全体の変革的な変化がもたらされる可能性があります。基本的なDAおよび検証レイヤーとして機能するB^2 Hubは、B^2 Networkの中核コンポーネントとしてだけでなく、他のビットコイン第2層にも力を与えています。競争の激しいビットコインLayer 2ソリューションの世界では、オフチェーンの機能拡張レイヤーが注目されており、B^2 HubとBTCKBはこの進化する風景の一部に過ぎません。

免責事項:

  1. この記事は再現されました [ ギークWeb3元のタイトル「新しいB^2テクノロジーロードマップの分析: ビットコインチェーンの下にDAおよび検証レイヤーの必要性」に基づいています。著作権は元の著者であるGeek Web3のFaustに帰属されます。転載について異議がある場合は、お問い合わせください。Gate Learn Team関連手続きに従って迅速に解決するため。

  2. この記事に表現されている見解や意見は、著者個人の視点を反映しており、投資アドバイスとして機能するものではありません。

  3. Gate Learnチームによって他の言語への記事の翻訳が提供されます。翻訳された記事は、言及せずにコピー、拡散、または盗用されない場合がありますゲート.io.

B^2新バージョンの技術ロードマップの分析:ビットコインのためのオフチェーンDAと検証レイヤーの必要性

初級編3/24/2024, 6:46:02 PM
B^2 Networkは、オフチェーンのDAネットワークを使用してデータの圧縮と検証の問題に対処する分散型データ可用性(DA)およびストレージプラットフォームです。これは、ビットコインのメインネットワークへの依存を減らすことを目的としています。B^2 Hubは、Celestiaと同様にDAレイヤーおよびオフチェーン検証レイヤーとして機能し、データの差し控えやその他の悪意のあるアクティビティを防ぎます。将来的には、B ^ 2ネットワークはビットコインレイヤー2を組み込んで、ビットコインエコシステム内にユニバーサルDAレイヤーとデータストレージレイヤーを確立する予定です。B^2ハブ・ノードはトランザクション・バッチを検証し、ストレージ・ノードはブロック・プロダクション権限を競い合ってインセンティブを獲得します。B^2ネットワークのワークフローには、シーケンサーが新しいブロックを作成し、アグリゲーターがZKプルーフ生成のためにそれらをProverに送信し、B^2ハブノードがデータハッシュを検証してビットコインチェーンに送信することが含まれます。ユニバーサルDAおよび検証レイヤーとして、B ^ 2ハブは他のビットコインセカンドレイヤーソリューションを強化する可能性があります。

概要:

B^2 Networkは、Celestiaの概念からインスピレーションを得て、ビットコインチェーン内にB^2 Hubとして知られるデータ可用性(DA)レイヤーを設立しました。このDAレイヤーネットワークは、新しいデータを多数の外部ノードに迅速に配布し、データの保留を防ぐためにデータサンプリングと消去符号化を実装しています。さらに、B^2 Hubネットワーク内のコミッターは、DAデータのストレージインデックスとデータハッシュをビットコインチェーンに公開アクセスするためにアップロードする責任があります。

DAレイヤーノードの負担を軽減するために、B^2 Hubの歴史データは永続的に保持されません。その結果、B^2は、Arweaveに似たストレージインセンティブメカニズムを採用して、より多くのノードが包括的な歴史データセットを保存するためのストレージ報酬を受け取ることを促進しようと努力しています;

・ステータス検証に関して、B^2はZKプルーフをオフチェーンで検証し、bitVMコンセプトを活用してZKプルーフ検証トレースに挑戦するハイブリッド検証手法を採用しています。不正検証プロトコルの信頼モデルに合致するよう、チャレンジャーノードがエラーを検知した際にチャレンジを開始し、B^2ネットワークの安全性を確保しています。ただし、ZKプルーフを利用しているため、このステータス検証プロセスは本質的にハイブリッドな性質を持っています;

B^2 Networkの将来のロードマップに沿って、EVM互換のB^2 Hubは、複数のBitcoin Layer 2ソリューションを接続するオフチェーン検証レイヤーおよびDAレイヤーとして機能する可能性があります。BTCKBに類似したBitcoinオフチェーン機能拡張レイヤーに進化することを目指しています。Bitcoinがさまざまなシナリオをサポートする上での制約を考慮すると、オフチェーン機能拡張レイヤーの開発がLayer 2エコシステム内で一般的な実践となることが予想されています。

B^2 Hub: ビットコインチェーン内の汎用データ可用性(DA)レイヤーおよび検証レイヤー

現在のBitcoinエコシステムは、機会とリスクの広がりを思わせるものであり、碑文の夏の余韻がこの領域に新たな息吹をもたらし、豊かな未開の土地のように富の香りが漂う状態となっています。今年の初めに登場したBitcoin Layer 2の出現により、このかつての荒涼とした風景は、多くのビジョナリーにとっての憧れの中心地に変貌しました。

問題の核心に戻ります: Layer 2の定義は個々の間で論点となっています。サイドチェーンですか?インデクサーですか?Layer 2という用語は接続を確立するチェーンを含みますか?単なるBitcoinとEthereumに依存するプラグインはLayerとして資格がありますか?これらの問いは、明確な解決策のない未解決の方程式に似ています。

イーサリアムおよびセレスティアコミュニティの視点によると、Layer 2はモジュラーブロックチェーンの明確なインスタンスを表しています。この文脈では、“第2レイヤー”と“第1レイヤー”との間に密接な相互依存関係が存在します。第1レイヤーのセキュリティは、第2レイヤーネットワークに部分的または大幅に受け継がれる可能性があります。セキュリティ自体には、DA、ステータス検証、引き出し検証、検閲耐性、再編成耐性などのさまざまなサブカテゴリが含まれます。

ビットコインネットワークの固有の制限を考慮すると、包括的なLayer 2ネットワークの支援には適していません。例えば、DAの観点から見ると、ビットコインのデータ処理能力は明らかにイーサリアムを大きく下回っています。平均ブロック生成時間が10分のため、ビットコインの最大データ処理速度はわずか6.8KB/sであり、イーサリアムの能力の約1/20です。そのため、混雑したブロックスペースによってデータの公開コストが高騰しています。

(ビットコインブロックにデータを公開するコストは、KBあたり$5に達することさえあります)

Layer 2が新しく追加されたトランザクションデータをBitcoinブロックに直接公開すると、高いスループットや低い取引手数料を実現できません。これを解決するための1つのアプローチは、Bitcoinブロックにアップロードする前にデータを大幅に圧縮することです。Citreaは現在、この方法を採用しており、複数のアカウント間で発生する状態変更(ステートディフ)を特定の期間にわたってBitcoinチェーンにアップロードし、対応するZK証明書とともに伴います。

これにより、誰でもビットコインメインネットワークからダウンロードした状態の差分とZKPの妥当性を検証できるようになりますが、チェーン上の軽量データを維持します。

(元のPolygon Hermezホワイトペーパーには、上記の圧縮スキームの原理が説明されています)

この方法によって達成された重要なデータサイズの圧縮にもかかわらず、多くの取引が短期間に多くのアカウントの状態変化を引き起こすシナリオでは、ボトルネックに直面する可能性があります。個々の取引データを直接アップロードするよりも軽量ですが、アカウントの変更をアップロードすることには相当なデータ公開コストがかかります。

その結果、多くのBitcoin Layer 2ソリューションは、DAデータをBitcoinメインネットワークにアップロードせず、CelestiaのようなサードパーティのDAレイヤーを利用することを選択しています。一方で、B^2は異なるアプローチを採用し、B^2ハブとして知られるチェーン直下のData Availability(DA)ネットワークを確立しています。この設計では、トランザクションデータやステートの差分などの重要なデータはオフチェーンに保存され、そのストレージインデックスとデータハッシュ(簡単のためにデータと呼ばれる)のみがBitcoinメインネットにアップロードされます。

これらのデータハッシュとストレージインデックスは、刻印と同様に、ビットコインチェーン上に記録されています。ビットコインノードを実行することで、個人はデータハッシュとストレージインデックスにローカルでアクセスすることができます。インデックス値を使用して、オフチェーンDAまたはストレージレイヤーから元のデータを取得できます。データハッシュにより、ビットコインチェーン上の対応するハッシュに対してオフチェーンDAレイヤーから取得したデータの正確性を検証できます。この直感的なアプローチにより、Layer 2ソリューションはDAの問題に対するビットコインメインネットへの依存を緩和し、取引コストを削減し、高いスループットを実現できます。

ただし、重要なのは、チェーン内のサードパーティDAプラットフォームがデータの保留プラクティスに従事する可能性があることを認識することです。これにより、新しいデータへの外部アクセスが阻害され、選択されたノードがデータアクセス権を制御するという現象、すなわち「データ保留攻撃」として知られる現象が発生する可能性があります。さまざまなDAソリューションがこの問題に異なる方法で対処しており、共通の目標はデータを迅速かつ広範囲に普及させ、一部のノードがデータアクセス権を制御するのを防ぐことです。

B^2ネットワークの公式新しいロードマップによると、そのDAソリューションはCelestiaを活用しています。後者の設計では、サードパーティのデータプロバイダが継続的にデータをCelestiaネットワークに提供します。Celestiaのブロック生産者はこれらのデータ断片をMerkle Treeの形式で整理し、それらをTIAブロックに詰め込んでネットワークにブロードキャストします。バリデータ/フルノード。

データが多く、ブロックが比較的大きいため、ほとんどの人がフルノードを実行する余裕がなく、軽量ノードのみを実行できます。軽量ノードは完全なブロックを同期しないが、その上に書かれたMerkle Treeのルートを持つブロックヘッダーのみを同期します。

B^2 Networkの最新のロードマップによると、そのDAソリューションはCelestiaからインスピレーションを得ています。この設計では、外部データプロバイダーが継続的にデータをCelestiaネットワークに供給します。Celestia内のブロック製造業者は、これらのデータ断片をMerkle Tree構造に整理し、それらをTIAブロックに埋め込み、ネットワークの検証者とフルノードに伝達します。データの量が膨大でブロックサイズが大きいため、多くの個人はフルノードの代わりに軽量ノードを実行することを選択しています。軽量ノードはMerkle Treeルートを含むブロックヘッダーのみを同期化します。

ライトノードはMerkle Treeの包括的なビューを欠いており、新しいデータコンテンツを検証することはできませんが、特定のリーフノードをフルノードにリクエストすることができます。フルノードは、リクエストされたリーフノードと対応するMerkle Proofsを提供して、セレスティアブロックのMerkle Tree内に存在することをライトノードに納得させ、それが偽造されたデータでないことを保証します。

(画像の出典:W3ヒッチハイカー)

Celestiaネットワークには、さまざまなフルノードから高頻度のデータサンプリングを行う多数のライトノードが存在します。これらのライトノードは、Merkle Treeから特定のデータ断片をランダムに選択し、それを他の接続されたノードに迅速かつ効率的に拡散させます。これにより、データを広範な人々やデバイスに配信することを目指しています。このアプローチにより、十分な数のノードが迅速に最新のデータを受け取ることができ、限られたデータプロバイダのグループに依存する必要がなくなります。この基本的な目標は、Data Availability(DA)とデータ配信の中核的な本質を強調しています。

ただし、前述の解決策が迅速なデータアクセスを可能にする効果的であるにもかかわらず、データソースの整合性を保証するものではありません。例えば、Celestiaのブロック生産者がブロックに誤ったデータを挿入する可能性があり、完全で正確なデータセットを再構築する取り組みを複雑化させることがあります。ブロック内のすべてのデータ断片を取得しても、それらを含めるべき完全なデータセットを復元することはできません(注:ここで「すべき」という言葉は重要です)。

さらに、特定の取引データが外部の当事者に開示されないシナリオでは、データ断片のわずか1%を保留することが、外部の者が全データセットを再構築するのを妨げる可能性があります。これはデータ保留攻撃の状況に似ています。

上述の文脈において、データの入手可能性の理解は、ブロック内の取引データが完全であり、アクセス可能であり、検証目的で容易に共有可能であるかどうかに関連しています。一般的な認識とは異なり、入手可能性は外部エンティティに対するブロックチェーンの歴史的データのアクセス可能性だけを示すものではありません。そのため、Celestiaの関係者やL2BEATの創設者は、データの入手可能性を「データのリリース」と改名することを提唱し、ブロック内の包括的でアクセス可能な取引データセットの公開を意味しています。

データの隠蔽攻撃の問題に対処するために、Celestiaは二次元の消去符号化を採用しています。ブロック内のデータフラグメント(消去符号)の少なくとも1/4が有効であれば、個人は元のデータセットを再構築することができます。しかし、ブロックプロデューサーが3/4の誤ったデータフラグメントを挿入した場合、データセットの再構築は実現不可能となります。特に、ブロック内のジャンクデータの過剰な存在は、軽量ノードによって容易に特定され、ブロックプロデューサーによる悪意のある活動に対する抑止となります。

このソリューションを実装することで、Celestiaはデータ配信プラットフォームにおけるデータの隠蔽を効果的に軽減します。B^2 Networkは、将来的にCelestiaのデータサンプリング手法を基本的な参照点として活用し、KZGコミットメントなどの暗号技術を統合する可能性があります。これにより、軽量ノードによって実施されるデータサンプリングおよび検証プロセスの効率と信頼性が向上します。

前述の解決策がDAプラットフォーム自体内のデータ保持に対処している一方で、レイヤー2のインフラストラクチャでは、DAプラットフォームとシーケンサーの両方がデータ保持能力を持っています。B^2 Networkのようなワークフローでは、シーケンサーはユーザートランザクションとその結果の状態変更を整理して処理し、それらをDAレイヤーとして機能するB^2 Hubノードに送信する前に新しいデータを生成します。

シーケンサーによって生成されたバッチ内で異常が発生した場合、データの隠蔽やその他の悪意のある活動のリスクがあります。そのため、B^2 HubのDAネットワークは、バッチを受け取るとその内容を細心の注意をもって検証し、問題のあるバッチを拒否します。したがって、B^2 HubはCelestiaに類似したDAレイヤーとして機能するだけでなく、RGB++プロトコルにおけるCKBと同様のオフチェーン検証レイヤーとしても機能しています。

(不完全な B^2 ネットワーク基本構造図)

B^2 Networkの最新テクノロジーロードマップに従い、B^2 Hubがバッチを受信し検証すると、一定期間バッチを保持してからローカルノードから期限切れになり削除されます。EIP-4844と同様のデータの陳腐化と損失の懸念に対処するために、B^2 Networkはバッチデータを永久に保存するストレージノードのネットワークを構築し、必要なときに歴史データを簡単に取得できるようにしています。

ただし、個人が強い理由がない限り、B^2ストレージノードを運用する可能性は低いです。 より多くの参加者にストレージノードを実行させ、ネットワークの信頼性を向上させるためには、インセンティブメカニズムを確立する必要があります。 そのようなメカニズムを実装するには、不正行為を防止するための措置が必要です。 たとえば、インセンティブシステムがデータをローカルデバイスに保存する個人を報酬する場合、データの一部をダウンロード後に削除し、自分の保存されたデータが完全であると虚偽の主張をするという不正行為のリスクがあります。—これは非常に一般的な詐欺の形態です。

Filecoinは、PoRepおよびPoStとして知られるプルーフプロトコルを採用しており、ストレージノードが指定された時間枠内でデータを安全に格納したことを証明する証明としてストレージ証明書を提供できるようにしています。ただし、このストレージ証明のアプローチにはZKプルーフの生成が関与しており、計算上の負荷が高く、ストレージノードに重要なハードウェア要件を課す可能性があり、経済的に実現不可能になる可能性があります。

B^2 Networkの最新の技術ロードマップでは、ストレージノードはArweaveに似たメカニズムを実装し、トークンインセンティブを獲得するためにブロックを生成する機会を競い合います。ストレージノードがデータを隠れて削除した場合、次のブロックプロデューサーになる可能性が低くなります。最も多くのデータを保持しているノードが、ブロックを成功製造し、より大きな報酬を受け取る可能性が高くなります。したがって、ほとんどのストレージノードにとって、完全な履歴データセットを維持することは、ブロック生産の見通しを最適化する上で有利です。

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

以前、B^2ネットワークのデータ可用性(DA)ソリューションについて詳細に説明しましたが、今度はその状態検証メカニズムについて詳しく説明します。 「状態検証スキーム」という用語は、レイヤー2が十分に「信頼できる」状態遷移をどのように確保するかに関連しています。

(L2BEATウェブサイトは、Scrollの5つの主要なセキュリティ指標を評価します。State Validationは状態検証スキームを指します)

Scrollのセキュリティ指標を評価するL2BEATのWebサイトで強調されているように、State Validationは特に状態検証スキームに対応しています。B^2 ネットワークおよびレイヤ 2 プロセスの大部分では、新しいデータはシーケンサによって発信されます。このエンティティは、ユーザーが開始したトランザクションと、その結果として生じる実行後のステータス変更を統合して処理します。これらの変更はバッチにバンドルされ、標準のレイヤー 2 フル ノードと B^2 ハブ ノードを含むレイヤー 2 ネットワーク内のさまざまなノードに配布されます。

バッチデータの受信後、B^2 Hubノードは細心の注意を払ってその内容を解析し、以前に言及された「状態の検証」を含む。基本的に、状態の検証は、シーケンサーが生成したバッチに記録された「取引実行後の状態変化の妥当性」を検証することを意味する。バッチ内の誤った状態は、B^2 Hubノードによって拒否される。

Proof-of-Stake(POS)パブリックチェーンとして機能するB^2 Hubは、ブロックプロデューサーと検証者を区別します。 定期的に、B^2 Hubのブロックプロデューサーは新しいブロックを生成し、それを他のノード(バリデータ)に伝播します。 これらのブロックには、シーケンサーによって提出されたバッチデータが含まれ、Celestiaに似たプロセスを反映しています。 外部ノードは頻繁にB^2 Hubノードからデータ断片をリクエストし、前述のストレージネットワークを含む多数のノードデバイスにバッチデータを配布することを容易にします。

B^2 Hub内には、コミッターとして知られる重要な役割があります。このエンティティは、バッチデータ(特にMerkleルート)をハッシュ化し、インデックスを保存し、それをビットコインチェーンに銘文形式で提出します。データハッシュとストレージインデックスにアクセスすることで、オフチェーンのDAレイヤー/ストレージレイヤーから完全なデータを取得できます。チェーンの下にN個のノードがバッチデータを保存していると仮定すると、ノードが外部エンティティとデータを共有する意思を持つと、関心を持つ任意の当事者が必要なデータにアクセスできます。このシナリオでの信頼の前提は1/Nです。

確かに、前述のプロセスでは、Layer 2の状態遷移を検証するB^2 Hubが、Bitcoinメインネットワークとは独立して動作し、純粋にオフチェーンの検証レイヤーとして機能しています。その結果、この時点でのLayer 2の状態検証スキームは、Bitcoinメインネットの信頼性には及びません。

一般的に、ZKロールアップはレイヤー1のセキュリティを完全に受け継ぐ能力を持っています。しかし、現在のビットコインチェーンの制約を考慮すると、基本的な計算のみをサポートし、直接的なZK証明検証機能がないことから、Bitcoin上のレイヤー2ソリューションは、特にCitreaやBOBなどのZKロールアップ技術を採用しているものは、Ethereumのセキュリティモデルには匹敵しないでしょう。

これまで、BitVMホワイトペーパーで詳しく説明されているように、ビットコインチェーンから複雑な計算プロセスを外部に移すことが、より実現可能なアプローチです。必要に応じて、必要最小限の計算のみがチェーンに移行されます。たとえば、ZKプルーフ検証中に生成された計算トレースは、公開され、外部機関と共有される可能性があります。複雑な計算ステップで何か矛盾が発生した場合、個人はこれらの論争のある計算をビットコインチェーンで検証できます。これには、ビットコインスクリプト言語を活用して、イーサリアム仮想マシン(EVM)などの専門仮想マシンの機能をエミュレートする必要があります。この取り組みにはかなりの技術努力が必要かもしれませんが、それでも実現可能な取り組みです。

参考文献:"BitVMのミニマリスト的な解釈:BTCチェーン上で不正証明を検証する方法(EVMまたは他のVMの操作コードを実行する)"

B^2 Networkの技術ソリューションでは、シーケンサーが新しいバッチを生成すると、それが集約者とプルーバに送信されます。その後、プルーバはバッチのデータ検証プロセスをZK-izeし、ZK証明書を生成し、最終的にEVM互換のB^2 Hubノードに転送します。ZKプルーフはSolidity契約を介して認証され、すべての計算プロセスは複雑な低レベルの論理ゲート回路に分解されます。これらの回路はBitcoinスクリプト言語でエンコードされ、フォーマットされ、適切なスループットを持つサードパーティのデータ可用性(DA)プラットフォームに提出されます。

個人が開示されたZK検証トレースを疑問視し、特定のステップでエラーが発生していると疑う場合、ビットコインチェーン上で「チャレンジ」を発行するオプションがあります。このチャレンジにより、ビットコインノードは直接争われたステップを精査し、必要に応じて適切な結果を出します。

(データサンプリングノードを除くB^2ネットワークの全体構造図)

では、誰が罰せられるのでしょうか? 実際に罰せられるのはCommiterです。B^2 Networkの枠組みの中で、Commiterは以前に言及されたデータハッシュをビットコインチェーンにブロードキャストするだけでなく、ZK証明書の検証「コミットメント」をビットコインメインネットワークに開示します。Bitcoin Taprootの特定の構成を通じて、個人はいつでもビットコインチェーン上でCommiterによって発行された「ZKプルーフ検証コミットメント」に疑問を提起し、異議を申し立てる能力を保持します。

「コミットメント」という概念を詳しく説明すると、個人がオフチェーンデータの正確性を主張し、それに対応する声明をブロックチェーンに公開することを指します。この声明は「コミットメント」として機能し、約束の値が特定のオフチェーンデータにリンクされています。B^2ソリューションでは、コミッターによって発行されたZK検証コミットメントに疑問を持つ当事者がいる場合、それに異議を唱える権利があります。

B^2 Hubが受信時にバッチを検証済みである場合、なぜZK証明書を「繰り返し詳細に」検証する必要があるのか疑問に思うかもしれません。なぜZKプルーフを導入する代わりに、直接的な挑戦のためにバッチ検証プロセスを公開しないのでしょうか? ZKプルーフの含有は、リリース前に計算トレースをより管理しやすいサイズに縮小するためのものです。Layer 2トランザクションと状態変化、ロジックゲート、ビットコインスクリプトに関する検証プロセスを公開すると、膨大なデータサイズが発生します。ZK化によって、このデータを効果的に圧縮してから配信します。

B^2のワークフローの簡潔な要約をご紹介します:

  1. B^2のシーケンサーは、新しいレイヤー2ブロックを生成し、複数のブロックをデータバッチにまとめます。これらのバッチは、B^2 Hubネットワーク内のアグリゲーターおよびバリデーターノードに転送されます。

  2. アグリゲータは、データバッチをProverノードに送信し、対応するゼロ知識証明の作成を可能にします。その後、ZK証明書がB^2のDAおよび検証ネットワーク(B^2 Hub)に送信されます。

  3. B^2 Hubノードは、アグリゲータからのZKプルーフがシーケンサーからのバッチと一致するかを検証します。成功した対応は検証通過を示します。検証されたバッチのデータハッシュとストレージインデックスは指定されたB^2 Hubノード(コミッター)によってビットコインチェーンに中継されます。

  4. ZKプルーフを検証するための計算プロセス全体は、B^2 Hubによって公開され、このプロセスのコミットメントは潜在的な挑戦のためにビットコインチェーンに提出されます。 成功した挑戦は、発行B^2 Hubノードに経済的ペナルティをもたらします(彼らのビットコインチェーン上のUTXOがアンロックされ、チャレンジャーに転送されます)。

B^2 Networkのこの状態検証アプローチは、ZKと詐欺証明の手法を統合し、ハイブリッド状態検証方法を構成しています。少なくとも1つの正直なノードがエラーを検出した場合にチャレンジすることを望んでいるチェーンによって、B^2 Networkの状態遷移の整合性に関する保証が提供されます。

西部ビットコインコミュニティのメンバーからの情報によると、ビットコインメインネットの将来のフォークに関する憶測があり、拡張された計算能力をサポートすることが検討されています。これにより、ビットコインチェーン上での直接ZKプルーフ検証が可能になり、ビットコインLayer 2全体の変革的な変化がもたらされる可能性があります。基本的なDAおよび検証レイヤーとして機能するB^2 Hubは、B^2 Networkの中核コンポーネントとしてだけでなく、他のビットコイン第2層にも力を与えています。競争の激しいビットコインLayer 2ソリューションの世界では、オフチェーンの機能拡張レイヤーが注目されており、B^2 HubとBTCKBはこの進化する風景の一部に過ぎません。

免責事項:

  1. この記事は再現されました [ ギークWeb3元のタイトル「新しいB^2テクノロジーロードマップの分析: ビットコインチェーンの下にDAおよび検証レイヤーの必要性」に基づいています。著作権は元の著者であるGeek Web3のFaustに帰属されます。転載について異議がある場合は、お問い合わせください。Gate Learn Team関連手続きに従って迅速に解決するため。

  2. この記事に表現されている見解や意見は、著者個人の視点を反映しており、投資アドバイスとして機能するものではありません。

  3. Gate Learnチームによって他の言語への記事の翻訳が提供されます。翻訳された記事は、言及せずにコピー、拡散、または盗用されない場合がありますゲート.io.

Start Now
Sign up and get a
$100
Voucher!