導入:

現在のビットコインレイヤー2シーンは、BTCエコシステムのるつぼに収束する多様な技術的ソリューションで賑わっています。研究、イノベーション、エンジニアリングの実装を通じて専門的な語彙と標準が継続的に進化するブロックチェーン分野での反復のペースが速いことを考えると、多くのプロジェクトは差別化と注意のために「コンセプト作成」または「コンセプトヒッチハイク」に頼っており、業界内の暗黙のルールになっています。たとえば、イーサリアム/セレスティアエコシステム内で最初にアクティブだったいくつかのモジュラーブロックチェーンプロジェクトは、「ビットコインレイヤー2」の時流に飛びつき、技術的なソリューションがロールアップ基準を満たしていないことが多いにもかかわらず、自らを「ロールアップ」と呼んでいます。ただし、「ロールアップ」という用語は重要な認識があり、プロモーション目的に有利です。多くのプロジェクトオペレーターは、自らをロールアップと名乗ったり、主流のロールアップの概念を「ソブリンロールアップ」などの曖昧な修飾語でフォークしたりしています。これらの「XXロールアップ」の層を剥がすと、多くのプロジェクトは基本的に「クライアント側の検証」または「サイドチェーン」に基づいており、便宜上「XXロールアップ」というスローガンを使用しているだけです。この宣伝戦略は一般的ですが、誤解を招く傾向があり、真実を求める人々に利益よりも害を及ぼす傾向があります。

（ナチ宣伝大臣ゲッベルスによってまとめられたこのアプローチは、「嘘に基づくプロパガンダ」として要約され、プロジェクト運営者の間で頻繁に観察されます。）では、どのようにしてこのような「ロールアップ概念のヒッチハイク」行動を見分けることができるのでしょうか？おそらく、最初の原則から始めて、ウェストや業界全体で広く受け入れられている基準に基づいて、異なるLayer2プロジェクトのカテゴリーとそのセキュリティレベルと機能を定義することが、明確さを提供するかもしれません。選択された解決策が何であるかは必ずしも重要ではありません。プロジェクトのメカニズム設計がLayer2ネットワークのセキュリティと信頼性を確保し、BTCメインネットを本当に強化しているかどうかが重要です。

この記事では、Bitcoin Layer2プロジェクトであるChainwayをケーススタディとして使用し、一部のプロジェクトの「Rollup」スローガンの背後に隠れている「クライアントサイド検証」の性質を分析します。 「Sovereign Rollup」と「クライアントサイド検証」を明確に区別し、スマートコントラクトに依存する業界標準のZKRollupsやOPRollupsとは大きく異なります。これは、Sovereign Rollupsやクライアントサイド検証がセキュリティと信頼性においてZK Rollupsに劣っていると言うものではありません。すべては、それらの具体的な実装の詳細に依存します。典型的にはクライアントサイド検証のLayer2であるChainwayは、BTCでトリガーされた検閲防止トランザクションスキームを提案し、MINAパブリックチェーンで使用されている再帰的ZKプルーフに依存して、オフチェーン検証を行っています。これにより、多くのBitcoin Layer2プロジェクトよりも先んじています。Chainwayの技術を研究することは価値があり、Bitcoin Layer2の観察者に重要な洞察を提供しています。（Chainwayのプロモーション画像はZK Rollupとしてブランド化されていますが、古いソリューションはクライアントサイド検証であり、ZKRは彼らの別のプロジェクトです。現在、オフチェーンクライアントコンセンサスや信頼性のあるメッセージ交換を実現していません。)

本文:Chainwayは、欧米のコミュニティでよく知られているビットコインレイヤー2プロジェクトであり、多くのKOLから「ZKロールアップ」と呼ばれることがよくありますが、その技術文書では「ソブリンロールアップ」と位置付けられています。最近、Chainwayは新しいプロジェクトであるCitreaも発表し、BitVMに基づくZKロールアップであると主張しています。ただし、CitreaはBitVMに基づくZK検証ソリューションの詳細をまだ明らかにしていないため、この記事ではChainwayの以前のソリューションの技術的な解釈に焦点を当てます。要約すると、Chainwayが公開している技術ソリューションには、BTCをDAレイヤーとして使用し、Ordinalsプロトコルを介してDAデータを公開し、Layer1での状態変更の正確性を検証する状態変更の詳細(State diff)+ ZK Proofを発行することが含まれ、完全で検証可能なトランザクションデータを公開することに相当します。しかし、Layer1はZK Proofsを直接検証しておらず、独立したクライアント/ノードによってオフチェーンで検証が行われており、Chainwayの現在のコードベースはオフチェーンのクライアント間でコンセンサスを得ておらず、ソーシャルメディア上でこの問題を解決すると主張していないため、Chainwayの公開されている技術ソリューションは本質的に「クライアント側の検証」カテゴリに属し、アセットブリッジングをサポートする暗号インデックス付きプロトコルにさえ似ています。次のセクションでは、Chainwayの特定の技術的実装を紹介し、そのセキュリティモデルを分析します。

Sovereign Rollup（主権ロールアップ）とは何ですか：データ可用性（DA）レイヤーの公開+オフチェーン検証

Chainwayの技術文書では、CelestiaからのSovereign Rollupの概念が使用されています。 Sovereign Rollupは、Ethereumコミュニティや広範な業界（スマートコントラクトRollup）内の主流のRollup概念とは根本的に異なります。では、Sovereign Rollupの構造は具体的にはどのようなものなのでしょうか？

本質的に、ビットコインに基づくソブリンロールアップは、「BTCブロックチェーン上でDAデータを公開するオフチェーンクライアントグループ/サイドチェーン」にいくらか似ています。その主な特徴は、レイヤー2の状態遷移/クロスチェーンアクションを検証するために、レイヤー1のスマートコントラクトを必要としないことです。基本的に、DAレイヤーとしてBTCを使用し、そのセキュリティモデルは「クライアント側の検証」とほぼ同じです。もちろん、より安全なソブリンロールアップソリューションの中には、ビットコインチェーン(サイドチェーンと同様)から離れたサードパーティの決済レイヤーに依存して、状態遷移の検証を実行するものもあります。さらに、異なる独立したクライアント/フルノード間では、特定の論争の的となるアクションについて「合意」に達するためのコンセンサスまたは信頼できるメッセージパッシングのレベルが存在します。ただし、一部のソブリン ロールアップ プロジェクトは、純粋に "クライアント側の検証" に基づいており、独立したクライアント/ノード間での信頼性の高いメッセージの受け渡しが欠けています。

「Sovereign Rollup」というユニークなコンセプトをより理解するためには、その対応物であるスマートコントラクトRollupと比較すると役立ちます。Ethereumでは、Layer 2のソリューションは主にArbitrumやStarkNetなどのスマートコントラクトRollupです。スマートコントラクトRollupの構造は、以下の図で視覚化することができます。

（ここに図を想像してください）

図では、モジュラーブロックチェーンナラティブに関連するいくつかの用語が以下のように説明されています。

• 実行レイヤー: ユーザートランザクションを実行し、ブロックチェーンの状態を更新し、データをDAレイヤーと決済レイヤーに提出します。

• 決済レイヤー: 実行レイヤーからの状態遷移を検証し、紛争（詐欺証明など）を解決し、L1-L2ブリッジングアセットを処理するためのブリッジモジュールを提供します。

• データ可用性（DA）レイヤー: 実行レイヤーによって提出された状態遷移データを受信し、このデータを信頼できる方法で誰でも利用できる大規模な掲示板のように機能します。

• コンセンサスレイヤー: トランザクションの順序の最終的な確定を保証します。その機能は、DAレイヤー（イーサリアムコミュニティのモジュラーなブロックチェーン層のアプローチにはコンセンサス層が含まれていません）の機能にかなり近いようです。
  
  スマートコントラクトロールアップのアーキテクチャから、イーサリアムは実行レイヤー以外の最後の3つのレイヤーの役割を担当していることがわかります。別の図では、イーサリアムがスマートコントラクトロールアップで果たす役割をより詳細に示すことができます。
  
  一方、Sovereign Rollupsは、イーサリアムのような一枚岩のブロックチェーンからこれらの責任の一部を分散化する点で大きく異なります。具体的には、状態遷移の検証や紛争処理のために第1層（レイヤー1）のスマートコントラクトに依存しない特徴があります。代わりに、これらのタスクはオフチェーンのクライアントやサードパーティの決済レイヤーによって管理され、ブロックチェーンシステムのスケーラビリティとセキュリティを実現する異なるアプローチが強調されています。

イーサリアム上のロールアップ契約は、Layer 2の状態遷移の正当性を検証するために、正当性証明または不正証明を受け取ります。ロールアップスマート契約は、モジュラーなブロックチェーンアーキテクチャにおいて決済層エンティティとして機能します。決済層契約には、しばしばイーサリアムからLayer 2にブリッジされた資産を処理するためのブリッジングモジュールが含まれています。データの可用性（DA）に関して、決済層契約は、シーケンサーに最新の取引データ/状態変更の詳細をチェーン上に投稿するよう指示することができます。チェーン上にDAを投稿しないと、ロールアップ契約に記録されたL2の状態を正常に更新することはできません。

（ZKロールアップまたは楽観的ロールアップを使用すると、DAデータをオンチェーンに投稿することができます。それがないと、決済レイヤーに記録された状態を更新することはできません。）ビットコイン/イーサリアムレイヤー2のセキュリティモデルとリスク指標をバレル理論で分析すると、スマートコントラクトロールアップは、実質的にレイヤー1のスマートコントラクトに大きく依存していることが明らかです。複雑なビジネスロジックをサポートするのが難しいBTCのようなレイヤー1にとって、イーサリアムのロールアップに合致するレイヤー2を構築することは本質的に不可能です。一方、主権ロールアップソリューションは、状態の検証/ブリッジングのためにレイヤー1で契約を必要としません。彼らのアーキテクチャは次のようになっています：（ここで、アーキテクチャの説明が欠落しており、イラストや詳細が意図されていたが提供されていません。）

主権ロールアップでは、データ可用性（DA）レイヤーの外部ノードが取引の実行および決済操作のエンティティとして機能し、より高い自由度を提供します。ワークフローは次のようになります:

ソブリンロールアップの実行レイヤーのノードは、トランザクションデータ/状態変更の詳細をDAレイヤーに送信し、決済レイヤー/クライアントはデータの取得と検証を試みます。決済レイヤ モジュールはレイヤ 1 に配置されていないため、理論的には、ソブリン ロールアップはレイヤ 1 と同等のセキュリティを持つブリッジを実現できないことに注意することが重要です。多くの場合、公証人の橋渡しやサードパーティのブリッジングソリューションに依存しています。現在、ソブリンロールアップ/クライアント検証スキームの実装は比較的単純であり、Ordinalsに似たプロトコルを使用してビットコイン(BTC)チェーン上のデータを公開するだけで済みます。オフチェーンの検証とコンセンサスに関しては、非常に柔軟性があります。実際、多くのサイドチェーンはBTCチェーン上でDAデータを公開するだけで、本質的に「BTCベースのソブリンロールアップ」になりますが、具体的なセキュリティには疑問があります。ただし、問題は、ビットコインのデータスループットが非常に低く、ブロックあたり最大4MB、平均ブロック時間が10分で、データスループットはわずか6KB / sに変換されることです。ソブリンロールアップを名乗るレイヤー2ソリューションは、BTCチェーン上のすべてのDAデータを公開できない可能性があるため、DAデータをオフチェーンで公開し、「コミットメント」の一形態としてBTCチェーンにデータハッシュを保存するなどの代替方法を選択したり、DAデータを高度に圧縮する方法(例: Chainwayが主張するように、State diff + ZK Proofを使用します)。明らかに、このモードは「ソブリン ロールアップ」の定義や適切なロールアップに準拠しておらず、セキュリティが疑わしいバリアントを表します。「Rollup」の旗印を掲げているほとんどのレイヤー2プロジェクトは、最終的にBTCチェーン上のすべてのDAデータを公開するわけではないため、その実用的なソリューションは、ホワイトペーパーで主張されている「ZK Rollup」や「OP Rollup」とは一致しない可能性が高いと予測しています。

最後に、主権ロールアップとスマートコントラクトロールアップの違いを簡単にまとめてみましょう：

1. アップグレード可能性:スマートコントラクトロールアップの更新イテレーションは、スマートコントラクトの更新を含み、開発チームがアップグレード可能なコントラクトを使用する必要があります。この種のスマートコントラクトのアップグレード権限は、一般的にロールアップ開発チームがマルチシグネチャを通じて制御します。一方、主権ロールアップのアップグレードルールは、従来のブロックチェーンのソフトフォークとハードフォークに類似しており、ノードは独自にバージョンを更新することができ、異なるクライアントはアップグレードを受け入れるかどうかを選択することができます。この観点から、主権ロールアップはアップグレード可能性の点でスマートコントラクトロールアップよりも優れています。

2. ブリッジ:理想的な条件下で、スマートコントラクトのロールアップ用のブリッジは最小限の信頼に準拠しますが、契約のアップグレード可能性はそのセキュリティに影響を与える可能性があります。主権ロールアップ方式では、開発者はレイヤー1チェーンの下でブリッジングコンポーネントを自ら構築する必要があり、構築されるブリッジはスマートコントラクトのブリッジよりも信頼される可能性が低いです。

BTC DA 構造

上記のテキストでは、BTCに基づいた主権ロールアップを実装するために、BTCをデータ可用性（DA）レイヤーとして機能させるためにOrdinalsプロトコルを使用することが肝要であると述べました。Chainwayはこの解決策を採用しています。

ChainwayシーケンサーからのDAデータ提出を調べることができます。トランザクションハッシュは次のとおりです:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000、以下のように示されています:

このトランザクションスクリプトは、Ordinals Protocolのアプローチを借りて、OP_0 OP_IFを使用してデータ書き込みを行うことで、RollupのDA（データの可用性）データをBTCチェーンに書き込むものです。これには、状態の変更とZKプルーフの公開が含まれます。これは、元のトランザクションデータを公開することと同等のセキュリティを提供しますが、データサイズを大幅に削減することができます。DAデータに加えて、シーケンサーはトランザクションにいくつかの認証データを書き込みます。その中で最も重要なのは、Rollupシーケンサーがその秘密鍵でDAデータに署名して、提出元がシーケンサーから来たことを確認することです。DAデータの提出を含むトランザクションには、トランザクションハッシュの末尾に16個のバイナリゼロ（つまり、連続した2バイトがゼロ）があることに注意することが重要です。この制限はコードで確認できます:

前述のトランザクショングラフの例では、乱数「b715」を使用してトランザクションのハッシュ値を調整し、その末尾が特定の16個のゼロを持つようにしています。この原則はビットコインマイニングに似ており、乱数ノンスを追加してハッシュの先頭Nビットをすべてゼロにし、特定の制約条件を満たします。この設計は、DA(データ可用性)データの取得の難しさを簡素化することを目的としています。Layer2ノードがDAデータにアクセスしたい場合、BTC(ビットコイン)ブロックをスキャンして、16個のゼロで終わるように設定されたすべてのトランザクションを探すだけでよく、ビットコインブロックチェーン上の他のトランザクションからデータを送信するときにチェーンウェイソーターによって開始されたトランザクションを効果的に区別します。以下のテキストでは、DAデータを含み、16個のゼロで終わるという要件を満たすような取引を「チェーンウェイ標準取引」と呼ぶ。この記事の焦点は、Chainwayが検閲耐性をどのように達成するかです。レイヤ 2 ソータは、特定のユーザからのトランザクション要求を意図的に拒否する可能性があるため、ユーザが検閲に抵抗するトランザクションを開始できるように、特別なスキームを採用する必要があります。この問題に対応して、Chainwayはユーザーが「強制トランザクション」を起動できるようにします。ユーザーがBTCブロック内でこのトランザクション宣言を送信すると、ChainwayソーターはLayer2でこのトランザクションリクエストを処理する必要があります。そうしないと、正常にブロックを生成できないか、生成されたブロックがオフチェーンクライアントによって認識されません。強制トランザクションのパラメータ構造は次のとおりです。

このトランザクションは、「Chainway Specification Transaction」としてビットコインブロックチェーンに送信され、トランザクションハッシュは16桁のゼロで終わります。 ChainWay sorterは、L2ブロックを生成する際に、BTCブロックチェーンで開示されたがまだL2台帳に記録されていない「Layer2 Specification Transactions」を含め、それらをMerkle Treeに集約し、そのMerkleルートをL2ブロックヘッダーに書き込みます。ユーザーがBTCブロックチェーン上で強制的なトランザクションを直接起動すると、ソーターはそれを処理する必要があります。そうでない場合、次の有効なブロックを生成することはできません。 BTCチェーンから外れたChainwayクライアントは、まずZKプルーフを検証してソーターによって提出されたL2ブロックの妥当性を判断し、L2ブロックヘッダーのMerkleルートをチェックし、ソーターが強制的なトランザクションリクエストを正直に含めたかどうかを判断します。ワークフローは以下のフローチャートを参照できます。スペースの制限により、以下の図はverify_relevant_tx_list内の条件判断が抜けています。

要約すると、Chainwayクライアント/ノードはBTCメインネットブロックと同期し、Chainwayソーターによって公開された「DAデータ」をスキャンします。これらのデータが指定されたソーターによって公開され、実際にBTCチェーンに送信されたすべての「チェーンウェイ標準トランザクション」が含まれていることを確認します。ユーザーが指定された基準を満たすトランザクションを「標準トランザクション」として構築し、BTCチェーンに送信できる限り、このトランザクションは最終的にChainwayクライアントのローカルL2台帳に含まれることは明らかです。そうしないと、Chainway ソーターによって解放された L2 ブロックがクライアントによって拒否されます。信頼性の高いオフチェーンのコンセンサス/アラートメッセージ送信と組み合わせると、Chainwayの反検閲トランザクションスキームは、ソブリンロールアップの理想的な検閲防止方法に近づきます。たとえば、一部のソブリンロールアップソリューションでは、無効なブロックが発生した場合、セキュリティを強化するためにオフチェーンクライアント間でアラート警告メッセージをブロードキャストし、特に完全なDAデータを同期できないライトクライアントにネットワークの異常を知らせることを明示的に述べています。ブロックに「必須トランザクション」が真実に含まれていない場合、明らかにオフチェーンアラートブロードキャストがトリガーされます。ただし、Chainwayはまだこの側面を実装していません(少なくとも現在公開されている資料とコードリポジトリは、この部分の技術的な実装に着手していないことを示しています)。

参考資料:Celestiaの研究者は、シーケンサー=アグリゲーター+ヘッダージェネレーターの6種類のロールアップバリアントを分析します。オフチェーンのクライアント/ノード間でコンセンサスが達成されたとしても、Arbitrum Oneは最終的にLayer1の反検閲特性を完全に継承し、Layer1のコントラクトを通じて「強制取引」がLayer1の台帳に含まれるようにするため、Chainwayの「強制取引」の反検閲効果はArbitrumのようなスマートコントラクトロールアップの有効性ほど堅牢ではありません。ソブリンロールアップは、検閲防止の有効性が最終的にオフチェーンコンポーネントに依存するため、この点でスマートコントラクトのロールアップに匹敵することは明らかです。また、強制取引をLayer2台帳にスムーズに含めることができるかどうかは、Layer1自体とは関係のないLayer2のオフチェーンエンティティの決定に依存するため、「Sovereign Rollups」や「Client Verification」スキームのアプローチは、Arbitrum One、Loopring、dydx、DegateなどのLayer1の反検閲特性を完全に継承することはできないことも判明しています。明らかに、オフチェーンクライアントの裁量のみに依存するChainwayのアプローチは、Layer1のDAの信頼性を継承しているだけで、完全な検閲防止特性を継承しているわけではありません。MINAの再帰的ZK証明に似ています。

このセクションでは、Chainwayの他のコンポーネントについてさらに紹介し、BTCをDAレイヤーとして使用するだけでなく、MINAに類似した再帰的なZK証明も実装しています。その全体的な構造は、次の図で示されています。

Chainwayネットワークのソーターは、ユーザートランザクションを処理した後、異なるアカウントの状態変更（ステートディフ）の詳細とともに、最終的なZK（ゼロ知識）プルーフを生成し、Bitcoin（BTC）ブロックチェーンに公開します。フルノードはBTCブロックチェーン上に公開されたChainwayのすべての履歴データを同期します。各ZKプルーフは、現在のブロックの状態遷移プロセスを証明するだけでなく、前のブロックのZKプルーフの妥当性も保証しなければなりません。このスキームに基づくと、新しいプルーフが生成されるたびに、前のプルーフを再帰的に確認し、最新のZKプルーフはジェネシスブロックから始まるすべてのZKプルーフの妥当性を保証できます。この設計はMINAのそれに似ています。ネットワークに参加する「軽量クライアント」（ブロックヘッダーのみを同期する「軽量ノード」とも呼ばれます）は、BTCブロックチェーンに公開された最新のZKプルーフの妥当性を検証するだけで、全体のチェーンの履歴データとすべての状態遷移が有効であることを確認できます。ソーターが悪意を持って、義務的なトランザクションを受け入れないか、以前のZKプルーフを再帰的に証明に使用しない場合、新しく生成されたZKプルーフはクライアントによって受け入れられません（生成されても認識されません）。下の図に示すように。

概要

この記事の冒頭で要約したように、Chainwayは基本的に、BTCをデータ可用性(DA)レイヤーとして使用するソブリンロールアップ/クライアント検証スキームです。ロールアップの検閲耐性を強化するために、Chainwayは強制トランザクションの概念を導入します。一方、Chainwayは再帰的なZKプルーフ技術を採用しているため、新しいノードはシーケンサーの出力をより信頼し、チェーン全体の履歴データの正確性をいつでも検証できます。Chainwayの現在の問題は、クロスチェーンブリッジの信頼メカニズムにあります。クロスチェーンブリッジソリューションの技術的な詳細にどのように対処するかを詳細に説明せずに、ソブリンロールアップアプローチを採用しているため、最終的なセキュリティを判断することは困難です。

今日、Chainwayの技術的ソリューションを掘り下げることで、プロジェクトのコミュニティによって推進されているテクノロジータイプは、主流の意味でのロールアップではないことがわかりました。すでに数十のビットコインレイヤー2プロジェクト(半年で数百に達する可能性がある)があることを考慮し、技術用語の認知コストを削減するために、レイヤー2ソリューションの分類とセキュリティ、機能の完全性、および評価の標準に関する詳細な調査を引き続き実施します。ご期待ください！

免責事項：

1. この記事は[から転載されましたギークWeb3]. All copyrights belong to the original author [Shew & Faust、极客web3]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
2. 責任の免責事項：この記事で表現される意見や見解は、著者個人のものであり、いかなる投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。