Tech Explained Chainway: Bitcoin Layer2プロジェクトはどのようにこの概念に手を出したのか？

DAレイヤー：実行レイヤーから提出された状態遷移データを受け取る大規模な掲示板で、このデータを非信頼化し、誰でも利用できるようにする

コンセンサスレイヤー：トランザクションの順序付けの最終性を保証するもので、DAレイヤー（イーサ）の機能に近いと思われる。

スマートコントラクトRollupのアーキテクチャから、実行レイヤーを除く3つのレイヤーの機能はイーサが担っていることがわかります。下の図は、イーサネットがスマートコントラクトのロールアップで担う役割を詳しく示しています。

イーサ上のロールアップコントラクトは、レイヤー2の状態遷移を検証するために、有効性証明または不正証明のいずれかを受け取ります。状態遷移を検証する。ここでのRollupスマートコントラクトが、実際にはモジュール型ブロックチェーンの決済レイヤーのエンティティであることは注目に値する。決済レイヤーの契約は、イーサがレイヤー2にブリッジする資産を処理するためのブリッジングモジュールを含むことが多い。

そしてDAの場合、決済層契約はシーケンサーSequencerに最新の取引データ/状態変更の詳細をチェーンにアップロードさせることができ、DAをチェーンにアップロードしなければ、ロールアップ契約に記録されたL2の状態をうまく更新することができません。

（ZKロールアップまたはOPロールアップ）。ZK RollupまたはOP Rollupでは、DAデータを強制的にアップリンクさせることができ、それなしでは決済レイヤーのレコードの状態を更新できません）

スマートコントラクトのロールアップは、レイヤー1のスマートコントラクトに大きく依存していることがわかります。

Smart Contract Rollup はレイヤー1のスマートコントラクトに大きく依存しており、複雑なビジネスロジックをサポートするのが難しいBTCでは、Ether Rollupに「沿った」レイヤー2を構築することは基本的に不可能であることがわかります。

そしてSovereign Rollupソリューションは、単純に状態の検証/ブリッジング処理を行うためにレイヤー1のコントラクトを必要としません。そのアーキテクチャを以下に示します:

Sovereign Rollupでは、DAレイヤーの外側にあるノード群が、より自由度の高いトランザクションの実行および決済オペレーションとして機能することがわかります。より高い自由度を持つエンティティとして機能します。 具体的なワークフローは以下の通りです。

Sovereign Rollupの実行レイヤーのノードは、取引データ/状態変更の詳細をDAレイヤーに送信します。データを取得し、検証作業を行う。決済レイヤーのモジュールはレイヤー1に存在しないため、Sovereign Rollupは理論上、レイヤー1のセキュリティと同等のブリッジを実装することができず、公証人ブリッジやサードパーティのブリッジングソリューションに頼ることが多いことは注目に値する。

現時点では、ソブリン・ロールアップ/クライアント側検証スキームは、着地がそれほど難しくなく、Ordinalsプロトコルに似た形で、BTCチェーン上にデータ公開を実装する必要があるだけだと思われます。オフチェーン検証やオフチェーンコンセンサスの部分に関しては、自由な遊びの余地が多く、多くのサイドチェーンでもDAデータをBTCに公開することができ、基本的には「BTCベースのソブリンロールアップ」になる。

しかし問題は、ビットコインのデータスループットが極めて低いことです。1ブロックあたり最大4MB、平均ブロック時間は10分で、データスループットはわずか6KB/秒です。現在ソブリン・ロールアップと呼ばれているLayer2のソリューションは、BTC上でDAデータをすべて公開できない可能性があります。自称ソブリン・ロールアップ・ソリューションであるLayer2は、BTCチェーン上ですべてのDAデータを公開することはできないかもしれません。そして、他の妥協策を採用するかもしれません。例えば、DAデータをオフチェーンで公開し、一種の「コミットメント」としてBTCチェーン上にデータハッシュを保存することです。あるいは、DAデータを高度に圧縮する方法を見つけるかもしれません（例えば、Chainwayが使用すると主張しているState diff + ZK Proof）。

しかし、明らかにこのモデルは「主権ロールアップ」や適切なロールアップの定義には当てはまらず、セキュリティに議論の余地がある変種です。私たちは、「ロールアップ」を使用する将来のLayer2プロジェクトのほとんどは、BTCチェーンに完全なDAデータをリリースしないと予測しています。そのため、可能性としては、ホワイトペーパーの「ZKロールアップ」とは異なる実践になるでしょう。"ZKロールアップ "と "OPロールアップ "のスローガン。

最後に、ソブリン・ロールアップとスマート・コントラクト・ロールアップの違いを簡単にまとめましょう。

まず、スケーラビリティです。スマートコントラクトの更新を伴うスマートコントラクト・ロールアップの更新反復では、開発チームはアップグレード可能なコントラクトを使用する必要があります。そのようなスマート・コントラクトのアップグレード権限は、一般的に複数の署名を持つRollup開発チームによって制御される。一方、ソブリン・ロールアップのアップグレード・ルールは、通常のブロックチェーンのソフトフォークとハードフォークに似ており、ノードは独自のアップデート・バージョンを選択でき、異なるクライアントはアップグレードを受け入れるかどうかを選択できます。この観点から、ソブリンロールアップはスマートコントラクトロールアップよりも優れています。

第二に、ブリッジです。スマート・コントラクト・ロールアップのブリッジは、理想的な条件下では、信頼最小化と一致しますが、コントラクトのスケーラビリティはそのセキュリティを損ないます。ソブリン・ロールアップ・スキームの下では、開発者はレイヤー1チェーンの下で独自のブリッジ・コンポーネントを構築する必要があり、おそらく構築されたブリッジはスマート・コントラクト・ブリッジほど信頼最小化にはならないでしょう。

BTC DA構築

上記の記事で、BTCベースのソブリンロールアップを実装するための中核は次のとおりであると述べました。Ordinalsプロトコルを使ったDAレイヤーとしてのBTCです。チェーンウェイはこの方式を採用しています。

トランザクションハッシュ:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000,で、ChainwayシーケンサーからDAデータのコミットを観察することができます。概略図は以下の通りです:

このトランザクションのスクリプトコードは、OP_0 OP_IFを使用するオーディナル・プロトコルからデータを実装するために借用しています。このトランザクションのスクリプトコードは、Ordinals ProtocolのOP_0 OP_IFの実装を借用し、RollupのDAデータをBTCチェーンに書き込みます（状態変化＋ZK Proofを投稿することで、セキュリティの点では元のトランザクションデータを投稿するのと同等ですが、データサイズははるかに圧縮されます）。

もちろん、DAデータに加えて、シーケンサーはトランザクション内にいくつかのフォレンジックデータも書き込みます。最も重要なのは、ロールアップシーケンサーが自身の秘密鍵を使用してDAデータに署名し、DAデータの提出がシーケンサーによって行われたことを保証することです。

ここで、DAデータ提出を含むトランザクションは、トランザクションハッシュの最後に16個のバイナリゼロ（つまり、連続した2バイトのゼロ）を持つことにも注意しなければなりません。コード内で、私たちはこの制限を見ることができます。

先ほどのトランザクショングラフの例にある乱数b715の目的は、ハッシュを取った後にこのトランザクションの値を調整し、最後に特定の16個のゼロを運ぶことです。その理由は、ビットコインをマイニングする際に乱数nonceを追加する必要性に似ており、特定の制約を満たすために、ハッシュの最初のNビットがすべてゼロになるようにします。

この設計は、DAデータの取得を簡素化するためです。Layer2の任意のノードがDAデータを取得したい場合、ブロックの末尾に16個のゼロを持つすべてのトランザクションについてBTCブロックをスキャンするだけでよい

これは、Chainwayシーケンサーがデータを送信するときに開始されるトランザクションと、ビットコインチェーン上の他のトランザクションと同じです。ビットコインチェーン上の他のトランザクション。後に、DAデータを含み、末尾の16個のゼロを満たすこのタイプのトランザクションは、「Cチェーンウェイ正規トランザクション」と呼ばれる。

それで、この記事のタイトルにあるポイントですが、チェーンウェイはどのようにして検閲への耐性を実現しているのでしょうか？Layer2シーケンサーは特定のユーザーからのトランザクション要求を意図的に拒否する可能性があるため、ユーザーが検閲に強いトランザクションを開始できるような特別なスキームを使用しなければなりません。

この問題に直面して、Chainwayはユーザーが「強制取引」を開始することを許可します。Layer2で取引リクエストを処理しないと、ブロックが正しく発行されなかったり、発行されたブロックがオフチェーンクライアントから認識されなかったりします。

必須取引のパラメータ構造は以下の通り：

取引は「Chainway」としてビットコインに提出される。トランザクションは、トランザクションハッシュの末尾に16個のゼロを持つ「Chainway canonical transaction」としてビットコインチェーンに提出され、ChainWayシーケンサーがL2ブロックを生成します。このブロックには、BTCチェーン上で公開されているが、L2元帳には含まれていない「Layer2 canonical transactions」が含まれている必要があり、それらを1つのブロックに集約します。それらをメルクルツリーに集約し、メルクルルートをL2ブロックヘッダに書き込みます。

ユーザーがBTCチェーン上で直接必須トランザクションを開始すると、シーケンサーはそれを処理しなければ次の有効なブロックを生成できません。BTCチェーン下のChainwayクライアントは、まずZKプルーフをチェックしてシーケンサーから提出されたL2ブロックの有効性を判断し、L2ブロックヘッダのMerkleルートをチェックし、シーケンサーが強制取引要求を正直に含めたかどうかを判断することができます。

ワークフローは以下のフローチャートを参照できる。

要約すると、Chainwayクライアント/ノードはBTCメインネットブロックを同期します。要約すると、Chainwayクライアント/ノードはBTCメインネットブロックを同期し、そこからChainwayシーケンサーによってポストされた "DAデータ "をスキャンし、それが指定されたシーケンサーによってポストされたこと、そしてそれが本当にBTCチェーンに提出されたすべての "Chainway正規トランザクション "を含んでいることを確認します。".

ユーザーが制約を満たす「正規の取引」を構築し、BTCチェーンに送信することができる限り、その取引は最終的にChainwayクライアントのローカルL2台帳に含まれ、そうでなければChainwayシーケンサーによってポストされたL2ブロックはクライアントによって拒否されることが簡単にわかります。ブロックはクライアントによって拒否されます。

信頼性の高いオフチェーンコンセンサス/アラートメッセージングと組み合わせると、Chainwayの検閲に強いトランザクションスキームは、検閲に強い理想的なソブリンロールアップアプローチに収束します。例えば、いくつかのソブリンロールアップスキームは、無効なブロックに遭遇した場合、セキュリティを強化するためにオフチェーンクライアント間でアラートアラートメッセージがブロードキャストされることを明言している。

ブロックが本来あるべき「必須トランザクション」を含んでいない場合、明らかにオフチェーンのアラートブロードキャストをトリガーしますが、チェーンウェイにはまだこれの実装がありません（少なくとも、この実装を経ていないことを示すデータとコードベースを公開できている限りでは）。

オフチェーンのクライアント/ノード間コンセンサスが実装されたとしても、 チェーンウェイの「強制トランザクション」は、まだ実装されていません。なぜなら、Arbitrum Oneは最終的に「強制取引」がレイヤー1の契約を通じてレイヤー2の台帳に含まれるようにし、レイヤー1の反検閲効果を完全に継承するからです。ソブリン・ロールアップはこの点で、明らかにスマート・コントラクト・ロールアップと同等ではなく、その検閲は最終的にオフチェーン・コンポーネントに依存します。

これはまた、「Sovereign Rollup」と「クライアント側の検証」スキームのアイデアは基本的にスマートコントラクトRollupと同じではないと判断します。Arbitrum OneやLoopring、dydx、Degateが完全にLayer1の検閲耐性を受け継ぐのと同じように、Layer1の検閲耐性を受け継ぐことはできません。なぜなら、トランザクションをLayer2の台帳に強制的に含めることができるかどうかは、Layer2のチェーン下のエンティティの決定とは対照的に、Layer2のチェーン下のエンティティの決定に依存するからです。レイヤー1自体から独立した、チェーンの下のエンティティに依存します。

チェーンウェイは、チェーン外のクライアントの自由な意思決定のみに依存するスキームであり、レイヤー1のDAの信頼性を受け継ぐだけで、検閲への耐性は受け継がないことは明らかです。

MINAライクな再帰的ZK証明

このセクションでは、DAレイヤーとしてBTCを使用することに加えて、MINAライクな再帰的ZK証明も実装しているChainwayの他のコンポーネントについてさらに説明します。を実装している。

Chainwayネットワークのシーケンサーは、ユーザートランザクションを処理した後、異なるアカウントの状態差分の状態変化の詳細とともに、最終的なZK証明を生成します。BTCチェーンに投稿されます。そしてフルノードは、BTCに投稿されたChainwayのすべての履歴データを同期します。各ZK証明は、現在のブロックの状態遷移プロセスを証明するだけでなく、前のブロックのZK証明が有効であることも保証する必要があります。

上記のスキームに基づくと、新しい証明が生成されるたびに、実際に前の証明を確認し、再帰的に、最新のZK証明の1つが、生成ブロックからのすべてのZK証明が有効であることを保証することがわかります。この設計はMINAに似ています。

「ライトクライアント」、つまりブロックヘッダを同期するだけのライトノードがネットワークに参加すると、BTCに開示された最新のZK証明が有効であることを確認するだけでよく、その後チェーン全体の履歴を確認します、すべての状態遷移は有効です。

シーケンサーが邪悪で、意図的に必須トランザクションを受け入れないか、再帰証明に最後のZK Proofを使用しない場合、次の図に示すように、生成された新しいZK Proofはクライアントに受け入れられません（生成されても認識されません）:

概要

この記事の一番最初に要約したように、Chainwayは本質的に、DAレイヤーとしてBTCを使用するソブリンロールアップ/クライアントサイド検証スキームです。Rollupの検閲耐性を高めるために、Chainwayは強制トランザクションの概念を導入しています。その一方で、Chainwayは再帰的ZK証明技術を使用しており、新規参入ノードがシーケンサーの出力をより信頼し、チェーン全体の履歴データにエラーがないことをいつでも確認できるようにしています。

Chainwayの現在の問題は、クロスチェーンブリッジ部分をどのように信頼するかという点にあります。また、ソブリン・ロールアップ方式を使用しているため、クロスチェーンブリッジ方式の技術的な詳細をどのように解決するつもりなのかを明示しておらず、最終的にどの程度セキュアになるのかを正確に判断するのは困難です。

本日、Chainwayの技術的ソリューションの詳細な分析を通じて、プロジェクトのコミュニティが宣伝しているタイプの技術は、主流の意味でのRollupではないことがわかりました。現在のBitcoin Layer2プロジェクトが数十のプロジェクトに達している（半年後には数百になるかもしれない）ことを考慮し、技術用語の認識コストを削減するためです。私たちは、Layer2プログラムの分類とセキュリティ基準、および機能的完全性の評価基準に関する綿密な研究を続けていきます！