Chainwayの技術解説：ビットコインLayer2プロジェクトはどのようにして流行りの概念に乗っかるのか（1）
TechFlow厳選深潮セレクト
Chainwayの技術解説：ビットコインLayer2プロジェクトはどのようにして流行りの概念に乗っかるのか（1）
Chainwayは本質的に、BTCをDA層として利用する主権Rollup／クライアント検証ソリューションである。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Shew & Faust、Geek web3
現在のビットコインLayer2分野はまさに百花繚乱であり、さまざまな技術的アプローチがBTCエコシステムという大熔炉に集中している。ブロックチェーン分野は進化が速く、専門用語や標準も研究開発と実装の過程で絶えず変化している。こうした背景のもと、多くのプロジェクトが差別化と注目を集めるために「概念創出」または「概念便乗」といった手法を採用しており、業界内の暗黙のルールとなっている。
たとえば、元々イーサリアム/Celestiaエコシステムで活動していたモジュラーブロックチェーンのプロジェクトも、その流れに乗って「ビットコインLayer2」の列車に乗り、「Rollup」と自称するようになった。しかし、その技術的アプローチはしばしば正統なRollupの定義に合致していない。
だが、「Rollup」という言葉には高い認知度があり、「Rollup」と称することは宣伝上有利である。多くのプロジェクトは、自らを強引に「Rollup」と名乗るか、主流のRollup概念をフォークして（たとえば「主権Rollup」のような曖昧な修飾語を加えて）便乗している。
しかし、こうした「XX Rollup」という外皮を剥がしてみると、多くのプロジェクトの動作原理は単なる「クライアント側検証」または「サイドチェーン」に過ぎない。要するに、「XX Rollup」というスローガンを利用して便宜を図っているだけなのである。このような宣伝方法は一般的ではあるが、誤解を招きやすく、真実を求める一般大衆にとっては害の方が利よりも多い。
（ナチス宣伝大臣ゲッベルスによる「嘘の宣伝」に関するまとめ。この手法は多くのプロジェクトで見られる）
では、我々はこうした「Rollup概念の便乗」行為をどのように見極めればよいだろうか？
あるいは、第一原理に立ち返り、西洋および業界全体で広く認められている基準に基づいて、異なるLayer2プロジェクトのアーキテクチャ分類とセキュリティレベル、機能的完全性を定義することで、霧の中でも花を識別できる「万華鏡写輪眼」を開けることができるだろう。言い換えれば、どのような技術を使うかではなく、プロジェクトのメカニズム設計がLayer2ネットワークの安全性・信頼性を確保し、BTCメインネットに真に価値を提供できるかどうかが本質なのである。
以下では、外国人によって開発されたビットコインLayer2プロジェクトChainwayを事例として、「Rollup」という宣伝スローガンの背後に隠された「クライアント側検証」の本質を分析する。これにより、「主権Rollup」「クライアント側検証」と、業界主流のZKRollupやOPRollupなどスマートコントラクトに依存するRollupアーキテクチャとの明確な違いがより鮮明になる。
もちろん、だからといって主権Rollupやクライアント側検証がZK Rollupより劣るというわけではない。すべては具体的な実装内容次第である。Chainwayは典型的なクライアント検証型Layer2ではあるが、「BTC上でトリガー＋チェーン外で検証」という検閲耐性トランザクションの提案を行い、MINAパブリックチェーンに類似した再帰的ZK Proofを採用しており、多数のビットコインLayer2プロジェクトをリードしている。
我々は、Chainwayに対する技術調査が非常に価値があると考えており、これはビットコインLayer2の観察者にとって重要な参考となる。
（Chainwayの宣伝画像。自らをZK Rollupと称しているが、実際のアプローチはクライアント側検証であり、現時点でチェーン外クライアント間の合意形成や信頼できるメッセージ交換を実現していない）
本文：Chainwayは西方コミュニティで比較的有名なビットコインLayer2プロジェクトであり、多くのKOLが宣伝する際に直接「ZK Rollup」と呼んでいる。一方、同プロジェクトの技術文書では自らを「主権Rollup」と位置づけている。最近Chainwayは新プロジェクトCitreaを発表し、BitVMベースのZK Rollupであると自称している。ただし、CitreaはまだBitVMに基づくZK検証スキームの実現方法を詳細に説明しておらず、本稿ではChainway既存の技術について重点的に解説する。
Chainwayが公開している技術アプローチを一言で要約すると：Ordinalsプロトコルを使ってDAデータを発行し、BTCをそのDA層とする。Layer1上で状態変化の詳細（State diff）とその正当性を証明するZK Proofを発行することで、完全かつ検証可能なトランザクションデータを公開することと同等の効果を得る。
（State diffとはアカウント状態の変化量のこと）
しかし、Layer1はZK Proofを直接検証せず、検証作業はチェーン外の独立したクライアント／ノードが行う。また、Chainwayの現在のコードベースは、チェーン外の独立クライアント間で合意形成を実現しておらず、公式もSNS上でこの問題の解決を宣言していない。したがって、現時点で公開されているChainwayの技術アプローチは本質的に「クライアント側検証」タイプに属し、むしろ資産橋接に対応したインスクリプションインデックスプロトコルに近い。
以下では、Chainwayの具体的な技術実装とそのセキュリティモデルについて詳しく紹介する。
主権Rollupとは：DA層へのデータ発行＋チェーン外検証
Chainwayの技術文書では、Celestiaの「主権Rollup (sovereign rollup)」という概念が使用されている。しかし、主権Rollupはイーサリアムコミュニティや業界主流のRollup概念（スマートコントラクトRollup）とは全く異なるものである。では、主権Rollupの具体的な構造はどのようなものなのだろうか？
実は、ビットコインに基づく主権Rollupは、「BTCチェーン上にDAデータを発行するチェーン外クライアント群／サイドチェーン」というものに近い。最大の特徴は、Layer1上のスマートコントラクトがLayer2の状態遷移やクロスチェーン操作を検証する必要がない点であり、本質的にはBTCをDA層として利用するだけであるため、そのセキュリティモデルは「クライアント側検証 (client side validation)」に大きく近い。
もちろん、セキュリティが高い主権Rollupのアプローチでは、BTCチェーン外の第三者決済層（サイドチェーンに類似）に依存して状態遷移の検証を行い、異なる独立クライアント／フルノード間に合意形成または信頼できるメッセージ伝達機構を持ち、議論のある行動に対して「一致」を達成する。しかし、一部の主権Rollupプロジェクトはまったくの「クライアント側検証」であり、独立クライアント／ノード間には信頼できるメッセージ伝達が存在しない。
「主権Rollup」という独特な概念をより深く理解するために、主権Rollupとそれに対応するスマートコントラクトRollupを比較してみよう。イーサリアム上のLayer2は基本的にすべてスマートコントラクトRollupであり、ArbitrumやStarkNetなどが該当する。スマートコントラクトRollupの構造は以下の図を参照：
上図から、モジュラーブロックチェーンの物語におけるいくつかの用語が確認できる。以下に説明する：
Execution（実行層）：ユーザーのトランザクションを実行し、ブロックチェーンの状態を更新し、DA層と決済層にデータを提出する
Settlement（決済層）：実行層の状態遷移を検証し、紛争を解決（例えば詐欺証明）、L1-L2間の資産橋接処理を行う橋渡しモジュールを提供する
DA層：巨大な掲示板のようなもので、実行層から提出された状態遷移データを受け取り、誰にでも非信頼的に提供する
Consensus（合意層）：トランザクション順序の最終性を保証する。DA層の機能と近い（イーサリアムコミュニティのモジュラーブロックチェーン分層方式では合意層を含まない）
スマートコントラクトRollupのアーキテクチャから、実行層以外の他の三層の機能はすべてイーサリアムが担っていることがわかる。下図はイーサリアムがスマートコントラクトRollupで果たす役割をさらに詳細に示している。
イーサリアム上のRollupコントラクトは有効性証明（validity proof）または詐欺証明（fraud proof）を受け取り、Layer2の状態遷移の正当性を検証する。ここで言うRollupスマートコントラクトは、モジュラーブロックチェーンにおける決済層の実体である。決済層コントラクトには通常、イーサリアムからLayer2へ資産を橋渡しするモジュールが含まれる。
DAに関しては、決済層コントラクトがシーケンサー（Sequencer）に対して最新のトランザクションデータ／状態変化の詳細をオンチェーンに記録することを強制的に要求できる。もしDAデータをオンチェーンに記録しなければ、Rollupコントラクトに記録されたL2状態を正常に更新できない。
（ZK RollupやOP Rollupは、DAデータのオンチェーン記録を強制でき、記録されなければ決済層の記録状態を更新できない）
参考資料：木桶理論でビットコイン／イーサリアムLayer2のセキュリティモデルとリスク指標を分解
以上から、スマートコントラクトRollupはLayer1上のスマートコントラクトに強く依存していることが分かる。複雑なビジネスロジックをサポートするのが困難なBTCのようなLayer1では、イーサリアムRollupに「準拠」するLayer2を構築することは基本的に不可能である。
一方、主権Rollupアプローチは、Layer1上のコントラクトによる状態検証／橋渡し処理を必要としない。そのアーキテクチャは下図の通り：
主権Rollupでは、DA層以外のノード群がトランザクションの実行と決済操作の主体となり、より高い自由度を持つ。具体的な動作フローは以下の通り：
主権Rollupの実行層ノードは、トランザクションデータ／状態変化の詳細をDA層に送信し、決済層／クライアントはデータを取得して検証を行う。注目すべきは、決済層モジュールがLayer1上に存在しないため、主権Rollupは理論上、Layer1同等のセキュリティを持つ橋を実現できない点であり、公証人型橋や第三者の橋接ソリューションに依存せざるを得ない。
現時点では、主権Rollup／クライアント検証アプローチの実装難易度は低く、BTCチェーン上でデータ発行を実現すればよく、Ordinalsプロトコルに類似した形式を採用できる。チェーン外の検証や合意形成部分については大きな自由度があり、多くのサイドチェーンがBTC上にDAデータを発行すれば、すでに「BTCに基づく主権Rollup」となり得る。ただし、その具体的なセキュリティには疑問が残る。
しかし問題は、ビットコインのデータスループットが極めて低いことにある。各ブロックの最大サイズは4MB、平均ブロック生成時間は10分であり、換算するとデータスループットはわずか6KB/sである。現在「主権Rollup」と自称するLayer2アプローチでは、すべてのDAデータをBTCチェーン上に発行できない可能性があり、他の妥協案を採用せざるを得ない。例えば、チェーン外にDAデータを発行し、datahashのみをBTCチェーン上に保存する「コミットメント」として扱う。あるいは、DAデータを高度に圧縮する方法（例えばChainwayが自称するState diff + ZK Proof）を見つける。
しかし明らかに、このパターンは「主権Rollup」または正統なRollupの定義に合致せず、一種の変種であり、そのセキュリティは疑わしい。我々は予測するが、今後大多数の「Rollup」と称するLayer2プロジェクトは、最終的にDAデータをBTCチェーン上に完全に発行しないだろう。そのため、実際の実装は十中八九、ホワイトペーパー上の「ZK Rollup」「OP Rollup」という宣伝スローガンに合致しない。
最後に、主権RollupとスマートコントラクトRollupの相違点を簡単にまとめる：
第一に、アップグレード性。スマートコントラクトRollupの更新は、スマートコントラクトのupdateを伴い、開発チームがアップグレード可能なコントラクトを使用する必要がある。このスマートコントラクトのアップグレード権限は通常、Rollup開発チームのマルチシグによって制御される。一方、主権Rollupのアップグレードルールは通常のブロックチェーンのソフトフォーク／ハードフォークに類似しており、ノードがバージョンを自主的に選択でき、異なるクライアントがアップグレードを受け入れるかどうかを選べる。この点において、主権RollupはスマートコントラクトRollupより優れている。
第二に、橋渡し（Bridge）。スマートコントラクトRollupの橋は理想的条件下では最小限の信頼で成立するが、コントラクトのアップグレード性がセキュリティに影響を与える。一方、主権Rollupのアプローチでは、開発者がLayer1チェーン外で橋接コンポーネントを自ら構築する必要があり、構築された橋は十中八九、スマートコントラクトの橋のように非信頼的とはならない。
BTC DA構造
前述したように、BTCに基づく主権Rollupを実現する鍵は、Ordinalsプロトコルを使用してBTCをDA層とすることにある。Chainwayはまさにこのアプローチを採用している。
ChainwayのシーケンサーによるDAデータ提出の取引を観察してみよう。そのトランザクションハッシュは次の通り：
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000、図解は以下の通り：
この取引のスクリプトコードは、Ordinals ProtocolがOP_0 OP_IFを使ってデータ書き込みを実現するアプローチを模倣しており、RollupのDAデータをBTCチェーンに書き込んでいる。（状態変化＋ZK Proofの発行。セキュリティ上はオリジナルのトランザクションデータ発行と同等だが、データサイズを大幅に圧縮できる）
もちろん、DAデータ以外にも、シーケンサーは取引内にいくつかの認証データを書き込んでいる。最も重要なのは、Rollupシーケンサーが自身の秘密鍵でDAデータに署名し、このDAデータ提出がシーケンサーによるものであることを保証している点である。
ここで注意すべきは、DAデータ提出に関連する任意の取引において、トランザクションハッシュの末尾に16ビットの0（つまり連続する2バイトが0）が存在すること。コード内ではこの制限が確認できる：
先ほどの例の取引図に出てくる乱数b715は、この取引のハッシュ値を調整し、末尾に特定の16個の0を付けるためのものである。これはビットコインマイニング時にnonceを追加してハッシュ値の先頭Nビットを0にするのと同じ理屈であり、特定の制限条件を満たすためのものである。
この設計はDAデータ取得の難易度を簡素化するためのものであり、Layer2の任意のノードがDAデータを取得する際、BTCブロック内で末尾が16個の0になっている取引をスキャンするだけでよく、Chainwayシーケンサーがデータ提出のために行った取引を、ビットコインチェーン上の他の取引と明確に区別できる。以降、このDAデータを含み、末尾が16個の0である取引を「Chainway規範取引」と呼ぶ。
ここで本文タイトルで触れた核心的な問いに戻る：Chainwayはどのようにして検閲耐性を実現しているのか？Layer2シーケンサーが意図的に特定ユーザーの取引リクエストを拒否する可能性があるため、ユーザーが検閲耐性取引を発動できる特別な仕組みが必要となる。
この問題に対し、Chainwayはユーザーが「強制取引（Forced Transaction）」を発行できるようにしている。ユーザーがBTCブロック内にこの取引を提出すれば、ChainwayシーケンサーはLayer2でこの取引リクエストを処理しなければならず、そうでなければ正常にブロックを生成できない、あるいは生成されたブロックがチェーン外クライアントに承認されない。
強制取引のパラメータ構造は以下の通り：
この取引は「Chainway規範取引」としてビットコインチェーンに提出され、トランザクションハッシュの末尾には16個の0が付く。ChainWayシーケンサーがL2ブロックを生成する際、BTCチェーン上に既に公開されたが、L2台帳に未収録の「Layer2規範取引」を必ず含めなければならず、これらをMerkle Treeに集約し、そのMerkle rootをL2ブロックヘッダに書き込む。
ユーザーがBTCチェーン上で直接強制取引を発行すれば、シーケンサーはそれを処理しなければ、次の有効なブロックを生成できない。BTCチェーン外のChainwayクライアントは、まずZK証明を検証してシーケンサーが提出したL2ブロックの有効性を確認し、L2ブロックヘッダのMerkle rootを検証して、シーケンサーが強制取引リクエストを正確に含んでいるかを判断できる。
その動作フローは以下の図を参照。ただし、篇幅の都合上、下図のverify_relevant_tx_listには条件判定が欠落していることに注意：
要するに、Chainwayクライアント／ノードはBTCメインネットのブロックを同期し、そこからChainwayシーケンサーが発行した「DAデータ」をスキャンして、それが指定されたシーケンサーによって発行されたものであること、かつBTCチェーン上に提出されたすべての「Chainway規範取引」を確かに含んでいることを確認する。
明らかに、ユーザーが制限条件に合致する「規範取引」を構築し、BTCチェーンに提出さえすれば、この取引は最終的にChainwayクライアントのローカルL2台帳に含まれることになり、さもなくばChainwayシーケンサーが発行するL2ブロックはクライアントによって拒否される。
信頼できるチェーン外合意／アラートメッセージ伝達と組み合わせれば、Chainwayの検閲耐性取引アプローチは理想化された主権Rollupの検閲耐性手法に近づく。例えば、一部の主権Rollupアプローチでは、無効なブロックが発生した場合、チェーン外クライアント間でアラート情報をブロードキャストしてセキュリティを強化すると明言しており、特に完全なDAデータを同期できないライトクライアントにもネットワーク異常を知らせることができる。
ブロックが「強制取引」を正確に含んでいなければ、明らかにチェーン外アラートブロードキャストがトリガーされるが、現時点ではChainwayはこの部分をまだ実現していない（少なくとも現時点で公開されている資料やコードベースからは、この技術的実装を行っていないことがわかる）。
参考資料：Celestia研究員が分析する6種のRollup変種：シーケンサー＝集約者＋ヘッダー生成者
仮にチェーン外クライアント／ノード間の合意形成を実現できたとしても、Chainwayの「強制取引」による検閲耐性の効果はArbitrumなどのスマートコントラクトRollupには及ばない。なぜなら、Arbitrum Oneは最終的にLayer1上のコントラクトによって「強制取引」がLayer2台帳に含まれることを保証し、Layer1の検閲耐性を完全に継承するからである。主権Rollupは明らかにこの点でスマートコントラクトRollupに追随できず、その検閲耐性は最終的にチェーン外部分に依存する。
これが決定づけるのは、「主権Rollup」および「クライアント側検証」アプローチの考え方は、Arbitrum OneやLoopring、dydx、Degateのように、Layer1の検閲耐性を完全に継承できないということだ。強制取引がLayer2台帳に正常に含まれるかどうかは、Layer2チェーン外の実体の意思決定に依存し、Layer1自体とは無関係である。
明らかに、Chainwayがチェーン外クライアントの自由裁量にのみ依存するこの単純なアプローチは、Layer1のDA信頼性は継承するが、検閲耐性は完全には継承していない。
MINAに類似した再帰的ZK証明
本節では、Chainwayの他の構成要素についてさらに紹介する。BTCをDA層として利用するだけでなく、MINAに類似した再帰的ZK証明も実現している。全体構造は以下の図の通り：
Chainwayネットワークのシーケンサーはユーザーの取引を処理した後、最終的なZK証明を生成し、各アカウントの状態変化の詳細（state diff）とともにBTCチェーン上に発行する。フルノードはBTC上に公開されたChainwayの全履歴データを同期する。各ZK証明は現在のブロックの状態遷移プロセスを証明するだけでなく、前回のZK証明も有効であることを保証しなければならない。
上記のアプローチに基づき、新しい証明を生成するたびに、実質的に前の証明が確認され、再帰的に続いていく。最新のZK証明一つで、創世ブロックからのすべてのZK証明が有効であることが保証できる。この設計はMINAに酷似している。
ブロックヘッダのみを同期する「ライトクライアント」（軽量ノード）がネットワークに参加する際、BTC上に公開された最新のZK Proofが有効であることを検証するだけで、チェーン全体の履歴データとすべての状態遷移が有効であることを確認できる。
もしシーケンサーが悪意を持って強制取引を受け入れず、または前回のZK証明を再帰的に使わなければ、生成された新しいZK証明はクライアントに受け入れられず（生成しても承認されない）、下図の通り：
まとめ
冒頭で述べた通り、Chainwayの本質はBTCをDA層とする主権Rollup／クライアント側検証アプローチである。Rollupの検閲耐性を高めるため、Chainwayは強制取引の概念を導入した。一方、再帰的ZK証明技術を用いることで、新たに参加するノードはシーケンサーの出力結果をより信頼でき、いつでもチェーン全体の履歴データが正しいことを確認できる。
Chainwayの現在の課題は、クロスチェーンブリッジの信頼性確保方法にある。主権Rollupアプローチを採用しているが、クロスチェーンブリッジの技術的詳細について説明しておらず、最終的なセキュリティがどうなるかはまだ判断できない。
本日、Chainwayの技術アプローチを深く分析することで、同プロジェクトコミュニティが宣伝する技術タイプが主流のRollupとは異なることが明らかになった。現在ビットコインLayer2プロジェクトは数十に達しており（半年後には百を超える可能性もある）、技術用語の理解コストを下げるため、我々は引き続きLayer2アプローチの分類、セキュリティ基準、機能的完全性評価基準について深く調査していく。ご期待ください！
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
