ログイン/ 登録

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

2024/02/01 13:47

従う

著者：Shew & Faust, Geek Web3, アドバイザー：Kevin He, BitVM Chinese Community Initiator, ex Web3 Tech Head@Huobi

現在のBitcoin Layer2トラックは、多種多様な技術的ソリューションが融解し、花開いたと言えるでしょう。BTCエコシステムという坩堝の中に蓄積され、集められている。ブロックチェーンの分野では反復のスピードが速いため、専門的な語彙や標準は、研究やイノベーション、エンジニアリングの着地の過程で常に変化しています。このような状況の中、多くのプロジェクトは差別化と注目を得るために「コンセプト構築」/「コンセプト擦り合わせ」アプローチを採用しますが、これは業界の暗黙のルールとなっています。

例えば、もともとイーサ/セレスティアのエコシステムで活動していた多くのモジュール型ブロックチェーンプロジェクトは、風を利用して「ビットコイン・レイヤー2」の列車に乗り、「ロールアップ」と名乗っています。技術的なソリューションはロールアップの基準を満たしていないことが多い。

しかし、「Rollup」のような用語は高度に受け入れられやすく、「Rollup」のバナーの下で宣伝しやすい。多くのプロジェクトは、ハードワイヤード（自称Rollup）か、主流のRollupコンセプトをフォーク（Sovereign Rollupのような曖昧な修飾語付き）しています。

しかし、「XX Rollup」のコートをはがすと、多くのプロジェクトの動作原理は、「XX Rollup」であるだけで、依然として単純な「クライアント検証」または「サイドチェーン」です。XXロールアップ」という宣伝文句を使って、自分たちが楽をしているだけなのだ。これはよくあることですが、しばしば誤解を招き、真実を探している一般の人々にとっては、良いことよりも悪いことの方が多いのです。

（ナチスの宣伝相ゲッペルスは次のように述べている。（ナチスの宣伝大臣ゲッベルスの「ウソつき宣伝」まとめ、多くのプロジェクトで常套手段）

このような「ロールアップコンセプト」は、どのように見分ければよいのでしょうか。

おそらく、欧米で、さらには業界で広く受け入れられている標準に基づいて、さまざまなLayer2プロジェクトのセキュリティと機能の種類とレベルを定義するという最初の原則が、暗闇を覗き込んでいるときに万華鏡の目を開く唯一の方法なのでしょう。言い換えれば、プログラムを採用することが最も重要なのではなく、プロジェクトのメカニズムの設計、Layer2ネットワークの安全性と信頼性を確保できるかどうか、BTCメインネットワークに真の力を与えることができるかどうかが核心なのだ。

以下では、外国人のビットコインLayer2であるChainwayをケーススタディとして取り上げ、「Rollup」のスローガンにあるプロジェクトのいくつかを分析するつもりです。Rollup」のスローガンは、プロジェクトの背後に隠された「クライアントサイド検証」の本質である。主権ロールアップ」と「クライアント側検証」、そして業界の主流であるZKRollup、またはOPRollupやスマートコントラクトの実装に依存する他のロールアップソリューションとの明らかな違いを通して、より明確に見ることができます。

もちろん、ソブリンロールアップやクライアントサイド検証がZKロールアップよりも安全性や信頼性が低いというわけではなく、すべてはその実装の具体的な内容次第です。 Chainwayは典型的なクライアントサイド検証型のLayer2ですが、「BTCでトリガー＋オフチェーンで検証」という検閲防止取引方式を提案し、次のような特徴を採用しています。

スマートコントラクトの実装は業界初です。

チェーンウェイの技術研究は、ビットコイン・レイヤー2のオブザーバーにとって貴重な参考資料になると考えています。

(Chainway's

本体: Chainwayは、欧米のコミュニティでは比較的よく知られているビットコインのLayer2プロジェクトです。Chainwayは欧米のコミュニティではよく知られたビットコインのLayer2プロジェクトで、多くのKOLが「ZK Rollup」として宣伝しており、Chainwayは技術文書で「Sovereign Rollup」と位置づけています。最近、Chainwayはまた、BitVMベースのZKロールアップであると主張する新しいプロジェクト、Citreaを発表しました。Citreaは、BitVMベースのZK検証スキームをどのように実装するのか、まだ詳しく説明していないため、この記事では、Chainwayの既存のスキームの技術的解釈に焦点を当てます。

Chainwayの公開されているソリューションを一言で要約すると、Ordinals経由でDAデータを公開し、そのDAレイヤーとしてBTCを使用し、Layer1で状態変化の詳細を公開し、Layer1で状態差分+状態変化の正しさの証明を公開する。diff + ZK 状態変更の正しさの証明、完全で検証可能なトランザクションデータの公開と同等の効果。

()State diffはアカウントの状態の変化量です）

しかし、Layer1はZK Proofを直接検証しないので、検証はチェーン下の独立したクライアント/ノードによって行われ、Chainwayの現在のコードベースはチェーン下の独立したクライアント間のコンセンサスを実装しておらず、ソーシャルメディアでも公式にこの問題を解決すると主張していません。そしてチェーンウェイの現在のコードベースは、チェーン下の独立したクライアント間のコンセンサスを実装しておらず、ソーシャルメディア上でこの問題を解決したと公式に主張していない。ですから、チェーンウェイが発表した現在の技術的な解決策は、本質的には「クライアント側の検証」というタイプのものであり、あるいは、ブリッジされたアセットをサポートするインスクリプション・インデキシング・プロトコルのようなものです。

次のセクションでは、Chainwayの具体的な技術的実装に焦点を当て、そのセキュリティモデルを分析します。

ソブリンロールアップとは：DAレイヤーのパブリッシングデータ＋オフチェーン検証

Chainwayの技術文書では、ソブリンロールアップというCelestiaのコンセプトが使われています。ソブリンロールアップは、イーサリアムコミュニティや業界で主流のロールアップコンセプト（スマートコントラクトのロールアップ）とはかなり異なります。では、ソブリンロールアップはどのように構築されるのでしょうか？

実際、ビットコインのソブリンロールアップは、「BTCチェーン上でDAデータを公開するオフチェーンクライアントグループ/サイドチェーン」のようなもので、その最大の特徴は、レイヤー1でスマートコントラクトを必要としないことです。その最大の特徴は、Layer1のスマートコントラクトがLayer2の状態遷移/クロスチェーンの振る舞いを検証する必要がないことであり、基本的にBTCをDAレイヤーとして使用するだけであり、セキュリティモデルは「クライアントサイドの検証」（client side validation）に非常に近い。

もちろん、より安全なソブリンロールアップソリューションのいくつかは、状態遷移の検証を完了するために、BTCチェーンの下にあるサードパーティの決済レイヤー（サイドチェーンに似ている）に依存しています。「合意」。しかし、いくつかのソブリン・ロールアップ・プロジェクトは、独立したクライアント/ノード間の信頼できるメッセージングがほとんどない、骨抜きの「クライアントサイド検証」である。

「ソブリン・ロールアップ」のユニークなコンセプトをよりよく理解するために、ソブリン・ロールアップのコンセプトをまとめることができます。strong>ソブリン・ロールアップを対応するスマート・コントラクト・ロールアップと比較することができます。イーサ上のLayer2は基本的に、ArbitrumやStarkNetのようなスマートコントラクトのロールアップです。

上の図では、以下のように説明される、モジュラーブロックチェーンの物語のいくつかの用語を見ることができます:

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

決済レイヤー：実行レイヤーの状態遷移を検証し、紛争（不正の証明など）を解決し、L1-L2ブリッジング資産を処理するブリッジモジュールを提供する

。p>
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プログラムの分類とセキュリティ基準、および機能的完全性の評価基準に関する綿密な研究を続けていきます！