ビットコインのスケーラビリティ：Layer2スキームと関連プロジェクトの説明

著者：Chakra; 翻訳者：0xjs@GoldenFinance

ビットコインのスケーリングには複数の道があり、私たちの一連の記事の第1部では、それらの道の1つである「ビットコイン・ネイティブ・スケーリング・ソリューション"、そしてもう1つの道は、レイヤー2と呼ばれるビットコインの上に追加のプロトコルレイヤーを構築することです。 レイヤー2ソリューションの最も重要な側面は、安全な双方向ブリッジとビットコインのコンセンサスセキュリティの継承です。

サイドチェーン

サイドチェーンのコンセプトは、ブロックストリームが「Hooked Sidechainsによるブロックチェーンイノベーション」を発表した2014年にさかのぼります。これはスケーリングに対する比較的基本的なアプローチを表しています。

サイドチェーンの仕組み

サイドチェーンはメインチェーンから独立して動作するブロックチェーンの一種であり、独自のコンセンサスプロトコルを持ち、メインチェーン上のイノベーションの実験場として使用することができます。サイドチェーンで不利な事象が発生した場合、その被害は完全にサイドチェーン自体に限定され、メインチェーンに影響を与えることはない。サイドチェーンは、より高いTPS（1秒あたりのトランザクション）を持つコンセンサスプロトコルを採用し、オンチェーンプログラマビリティを強化し、強化されたBTC機能を促進することができます。

サイドチェーンは、双方向ペグまたは一方向ペグによって、異なるブロックチェーン間でのビットコインの移動を可能にすることができます。しかし現実には、BTCはメインのビットコインネットワーク上にしか存在できないため、サイドチェーン上のBTCをメインのビットコインネットワーク上のBTCにリンクするためのアンカーメカニズムが必要です。

一方向ペッグは、ユーザーがメインネットから利用不可能なアドレスにBTCを送って破棄し、サイドチェーン上で同量のBTCを鋳造する必要がありますが、このプロセスは可逆的ではありません。双方向ペグは一方向ペグを改良したもので、メインチェーンとサイドチェーンの間でBTCを行き来させることができる。双方向ペグは、利用できないアドレスに送ってBTCを破壊する代わりに、マルチシグネチャやその他の制御スクリプトを通じてBTCをロックし、サイドチェーン上に新しいBTCをキャストします。ユーザーがメインネットに戻りたいときは、サイドチェーン上のBTCが破壊され、元のロックされたBTCがメインネット上で解放されます。

一方向フックは、メインのビットコインネットワークに関連する状態を管理する必要がないため、双方向フックよりも実装がはるかに簡単です。しかし、ワンウェイペギングによって作成されたサイドチェーン資産は、逆アンカーリングのメカニズムがないため、無価値になる可能性があります。

メインチェーン上のロックされたトランザクションとサイドチェーン上の破壊されたトランザクションを検証するための異なるスキームとセキュリティレベルがあります。最も単純な方法は、マルチシグネチャーの参加者を介した外部検証ですが、これは中央集権化という高いリスクを伴います。より良い選択肢は、SPV証明を使用した分散型検証である。しかし、メインのビットコインネットワークにはSPV検証を実行するために必要なプログラミング機能がないため、通常はマルチシグネチャエスクローなど、他の方法を使用する必要があります。

<

課題と方法論

サイドチェーンの主な批判には次のようなものがあります:

1.アセットクロスチェーンの検証者への依存: スマートコントラクトはまだビットコインメインネットで利用できないため、クロスチェーンのアセット転送はトラストレスコントラクトロジックで管理できません。サイドチェーンからビットコインに資産を戻すには、一連の検証者に依存する必要があり、信頼の仮定と詐欺のリスクが生じます。

2.サイドチェーンはメインチェーンのセキュリティを継承できない：サイドチェーンはメインネットワークから完全に独立して動作するため、メインネットワークのセキュリティを継承できず、悪意のあるブロック再編成につながる可能性があります。

これらの問題に対処するため、サイドチェーンは当局への依存（フェデレーション）、経済的セキュリティ（PoS）、分散型ビットコインマイナー（マージマイニング）、ハードウェアセキュリティモジュール（HSM）などのアプローチを取ってきました。ビットコイン上の資金の保管とサイドチェーン上のブロック生成は、異なる役割によって管理され、より複雑なセキュリティメカニズムを導入することができます。

ケーススタディ

Liquid

サイドチェーンの最も初期の形態の1つは連合型サイドチェーンで、メインネットワーク上の資産の保管とサイドチェーン上のブロック生成を担当する検証者として、事前に選択されたエンティティのセットに依存していました。

Liquidは連合型サイドチェーンの典型的な例で、15人の参加者が検証者として機能している。秘密鍵の管理は公開されておらず、検証には15人のうち11人の署名が必要です。Liquidサイドチェーンのブロック生成も、これら15人の参加者によって維持されています。このフェデレーションではノード数が少ないため、1秒あたりのトランザクション（TPS）が高くなり、DeFiが主な応用分野であるスケーラビリティの目標が達成されます。

しかし、フェデレーション型サイドチェーンモデルには、中央集権的な重大なセキュリティリスクが伴います。

Rootstock（RSK）

RSKもまた、主要なネットワーク資金をホストする役割を担う15ノードによって管理されており、検証に必要な署名は8つだけです。Liquidとは異なり、RSKの複数署名鍵はハードウェアセキュリティモジュール（HSM）によって管理され、フックコマンドはProof-of-Work（PoW）コンセンサスに基づいて署名されるため、鍵にアクセスできる検証者によるエスクロー資金の直接操作を防ぐことができます。

サイドチェーンのコンセンサスに関して、RSKはメインネットの演算を使用してサイドチェーンのトランザクションを保護するためにマージマイニングを使用し、メインネットの演算の大部分がマージマイニングに使用される場合、サイドチェーンの二重フラワー攻撃を効果的に防ぐことができます。

RSKはマージマイニングに基づいて改善し、フォークセンシングによってフォークの動作に関するオフチェーンコンセンサスに介入することで、低演算の下でサイドチェーンのセキュリティを確保し、二重フラワー攻撃の可能性を低減します。ダブルフラワー攻撃の可能性を減らす。

しかし、マージマイニングはマイナーのインセンティブを変え、マイナーの抽出可能価値（MEV）のリスクを悪化させ、システムを不安定化させる可能性があります。時間の経過とともに、マージマイニングはマイニングの集中化を高めるかもしれません。

スタックス

スタックスは、サイドチェーンブロックのハッシュをビットコインブロックにコミットし、チェーン履歴をビットコインに固定することで、ビットコインと同じ究極の確実性を達成します。Stacksのフォークは、Bitcoin自体がフォークするときにのみ発生し、ダブルフラッシュ決済攻撃への耐性を高めます。

sBTCは、最大150人のメインネット検証者を可能にする誓約ブリッジを利用した新しいトークンとインセンティブモデルを導入します。検証者は入出金を承認するためにSTXトークンを誓約する必要があります。誓約ブリッジのセキュリティは、誓約された資産の価値に大きく依存するため、誓約された資産の価格が大きく変動する期間中、BTCのクロスチェーンのセキュリティにリスクをもたらします。

他のサイドチェーン案は現在、コミュニティで広く議論されています。

Drivechain

これらの中で最も注目すべきは、2015年のPaul Sztorc氏のDrivechain提案で、BIP 300（ペッグ機構）とBIP 301（ブラインドマージマイニング）に主要技術を割り当てています。BIP301は、ビットコインマイナーがトランザクションの詳細を検証することなく、サイドチェーンのブロック生産者になることを可能にします。

ビットコインマイナーは、引き出しトランザクションの承認も担当します。マイナーは、自分が採掘したブロックのcoinbaseトランザクションにOP_RETURN出力を作成することで、引き出し提案を開始します。その後、他のマイナーは自分が採掘した各ブロックでその提案を支持または反対することで投票することができます。撤退トランザクションがしきい値（13,150ブロック）を超えると、ビットコインのメインチェーン上で実行され、確認されます。

実際、採掘者はDrivechain上の資金を完全に管理している。資金が盗まれた場合、ユーザーは合意形成が難しいユーザー起動型ソフトフォーク（UASF）を通じてしか救うことができない。さらに、Drivechainにおけるマイナーのユニークな立場は、Etherで実証されているように、MEVリスクを増加させます。

Spacechain

Spacechainは異なるアプローチを取っており、Permanent One-Way Peg（P1WP）を使用しています。これにより、ユーザーはSpacechainでトークンを受け取るためにBTCを破棄し、資金のセキュリティを完全にバイパスします。これらのトークンはSpacechain上のブロックスペースの入札にのみ使用され、価値の保存はありません。

サイドチェーンを保護するため、Spacechainはブラインドマージマイニングを採用しており、ユーザーはANYPREVOUT（APO）を使ってブロックを構築する権利を公然と入札する。ビットコインのマイナーは、サイドチェーンのブロックを検証することなく、自分のブロックの中にSpacechainのブロックヘッダを提出するだけです。しかし、Spacechainの立ち上げにはビットコインがコベナントをサポートする必要があり、ビットコインコミュニティはコベナントオプコードを追加するソフトフォークの必要性についてまだ議論している。

全体として、Spacechainの目標は、ビットコインと同様に分散化され検閲に強いサイドチェーンを実装することであり、同時にブロックオークション機能を通じてプログラム可能性を高めることです。

Softchain

Softchainは、Ruben Somsen氏による別の双方向ペッグ（2wp）サイドチェーンの提案で、サイドチェーンを保護するためにPoW FPコンセンサスメカニズムを利用しています。通常、ビットコイン全体のノードはSoftchainのブロックヘッダをダウンロードし、プルーフオブワークロードを検証する。フォークの場合、ブロックの有効性を検証するために、隔離されたブロックと対応するUTXOのコミットメントセットをダウンロードします。

2wpメカニズムでは、受信ペグでメインチェーン上に入金トランザクションが作成され、Softchainはそれを参照して資金を取得し、送信ペグでSoftchain上に引き出しトランザクションが作成され、メインチェーンはそれを参照してより長いチャレンジ期間の後にBTCを取り戻します。

Softchainの提案は、ビットコインのメインネットのフルノードに追加の検証コストを追加し、Softchain内のコンセンサス分裂はメインネットのコンセンサスに影響を与え、ビットコインへの攻撃の可能なベクトルを提起する可能性があります。

Lightning Network

Lightning Networkのホワイトペーパーは2015年に発表され、ビットコインネットワークの第2層のピアツーピア決済プロトコルとして2018年に稼働し、大量の少額で高頻度のトランザクションをオフチェーンで処理するように移動させるように設計され、ビットコインネットワークの最も有望なスケーリングソリューションと長い間みなされてきました。

コアモジュール

ライトニングネットワークの実装は、ネットワークトランザクションを安全にするために連携するビットコイン内のいくつかの重要なモジュールに依存しています。

まず、署名済みのトランザクションがあります。これらのトランザクションは、SegWitのアップグレードにより安全になりました。SegWitはトランザクションデータの残りの部分から署名を分離し、トランザクションの改ざん可能性、サードパーティおよびセカンドパーティのトランザクションの改ざんなどの潜在的な問題に対処します。ライトニング・ネットワークにおけるオフチェーン計算のセキュリティは、取引相手からの取消不能なコミットメントによって保証され、これは事前署名されたトランザクションを通じて実施される。ユーザーが取引相手から事前署名されたトランザクションを受け取ると、いつでもそれをブロックチェーンにブロードキャストして約束を果たすことができる。

次はマルチ署名だ。2者間で頻繁に行われるオフチェーンでの資金移動には、両者が管理する媒体が必要であるため、通常は2-of-2スキームを使用した複数の署名が必要となります。これにより、送金は相互の同意によってのみ行われることが保証される。

しかしながら、2-of-2の複数署名はアクティビティ問題につながる可能性があります。つまり、一方の当事者が協力しない場合、もう一方の当事者は複数署名アドレスから資金を送金することができず、元の資金が失われることになります。資金返却のためのタイムロックを備えた契約に事前に署名することで、一方の当事者が非活動的であっても、もう一方の当事者が当初の資金を回収できるようにすることができます。

最後に、ハッシュロックは複数の状態チャネルを接続するために使用され、ネットワーク効果を生み出す。ハッシュの元画像（プリイメージ）は通信手段として機能し、複数のエンティティ間で正しい操作を調整する。

操作の流れ

双方向チャネル

ライトニングネットワークを使って取引を行うには、まず両者がビットコイン上で双方向の支払いチャネルを開く必要があります。両者はチェーン上で無制限に取引を行うことができ、ビットコインのブロックチェーンに更新されたステータスを送信して決済を行い、すべての取引が完了した後に決済チャネルを閉じる。

具体的には、ペイメントチャネルの実装には以下の重要なステップが含まれます：

1.マルチシグネチャアドレスを作成する。両当事者はまず、チャネルの資金調達ロックとして機能する2対2のマルチシグネチャアドレスを作成する必要があります。各パーティは署名に使用する秘密鍵を保持し、自身の公開鍵を提供します。

2.チャネルを初期化する。各パーティはチェーン上でトランザクションをブロードキャストし、一定数のビットコインをマルチシグネチャアドレスにロックします。この取引はチャネルの「アンカー」取引として知られています。

3.チャネルステータスの更新。チャネルで支払いが行われると、両当事者は事前に署名したトランザクションを交換し、チャネルのステータスを更新する。更新のたびに、現在の資金配分を表す新しい「コミットメント・トランザクション」が生成される。コミットメント・トランザクションには2つの出力があり、それぞれが両当事者間の資金のシェアに対応する。

4.最新ステータスのブロードキャスト。どちらの当事者も、資金の取り分を引き出すために、いつでも最新のコミットメント取引をブロックチェーンにブロードキャストすることができます。相手方が古い状態をブロードキャストするのを防ぐため、各コミットメント取引には対応する「ペナルティ取引」が付随しており、相手方が不正を行った場合、一方の当事者が相手方の資金をすべて請求できるようになっています。

5.チャネルの閉鎖。両当事者がチャネルを閉じることを決定した場合、両当事者は協力して「決済取引」を生成し、ブロックチェーンに最終的な資金分配をブロードキャストすることができます。これにより、マルチシグネチャアドレスに閉じ込められた資金が当事者の個人アドレスに解放されます。

6.オンチェーン仲裁。当事者がチャンネルを閉じることに合意できない場合、当事者のどちらかが一方的に最新のコミットされたトランザクションをブロードキャストし、オンチェーン仲裁プロセスを開始することができます。一定期間（例えば1日）内に争いがなければ、コミットメントトランザクションの配分に基づいて両当事者に資金が分配されます。

決済ネットワーク

決済チャネルは、即時条件としてハッシュロックを使用し、フォールバックとしてタイムロック署名決済を使用するHTLC（Hash Time-Locked Contracts）を使用して、マルチホップルーティングをサポートするネットワークを形成するために相互接続することができます。の原画を、時間ロックが切れる前にやりとりできるようにします。

2人のユーザー間に直接のチャネルがない場合、ルーティングされたパスを介してHTLCを使用して支払いを完了することができます。このプロセスにおいて、ハッシュの原画像Rは、支払いの原子性を保証する上で重要な役割を果たします。さらに、HTLCの時間ロックはルーティングパスに沿って減少するように設定され、各ホップで支払いを処理して転送するのに十分な時間があることを保証します。

課題

根本的に、ライトニングネットワークは、フェイルセーフ保護を提供するためにタイムロックされたスクリプトを使用して資産に究極の保護を提供する一方で、ピアツーピアのステートチャネルを介したブリッジング資産の外部信頼の前提を回避します。これにより、取引相手が活動を停止し、協力しない場合、一方的な退出が可能になる。その結果、ライトニング・ネットワークは決済シナリオにおいて高い実用性を発揮しますが、以下のようないくつかの制限があります：

1.チャネル容量の制限：ライトニング・ネットワークの決済チャネルの容量は、最初にロックインされた資金によって制限され、チャネル容量を超える決済には対応できません。このため、商品取引など特定のユースケースが制限される可能性があります。

2.オンラインと同期の要件: 支払いをタイムリーに受け取り、転送するためには、ライトニングネットワークのノードはオンライン状態を維持する必要があります。ノードが長期間オフラインになると、チャネルの状態更新が見逃され、同期が取れなくなる可能性があります。これは個々のユーザーやモバイルデバイスにとって課題となり、ノードの運用コストも増加します。

3.流動性の管理：ライトニングネットワークのルーティング効率は、チャネル間の流動性の分配に依存します。資金が不均等に分配されると、特定の支払い経路が非効率になり、ユーザーエクスペリエンスに影響を与える可能性があります。チャネルの流動性バランスを管理するには、一定の技術的および資金的リソースが必要です。

4.プライバシー：実行可能な決済経路を見つけるために、ライトニング・ネットワークのルーティング・アルゴリズムは一定レベルのチャネル容量と接続情報を知る必要があります。また、決済チャネルの開閉により、参加者の情報が明らかになる可能性もあります。

RGB

RGBプロトコルの当初のコンセプトは、クライアント側の認証とワンタイムシールというピーター・トッドのアイデアに触発されたものでした。スケーラブルでプライバシーを保護するビットコインのレイヤー2プロトコルとして、2016年にGiacomo Zuccoによって提案されました。

コアコンセプト

クライアントサイド認証

ブロックチェーンにおける認証プロセスでは、トランザクションで構成されるブロックをネットワーク全体にブロードキャストし、各ノードがそれらのブロック内のトランザクションを計算して検証できるようにします。これは効果的に公共財を生み出し、ネットワーク内のノードは検証されるトランザクションを提出する各個人を支援し、ユーザーは検証の報酬としてトランザクション手数料としてBTCを提供します。クライアント側の検証はより個人中心であり、状態の検証はグローバルに行われるのではなく、特定の状態遷移に関与する個人によって行われる。トランザクションを生成する当事者のみがこれらの状態遷移の正当性を検証できるため、プライバシーが大幅に強化され、ノードの負担が軽減され、スケーラビリティが向上します。

ワンタイムシール

ピアツーピアの状態遷移は、完全な状態遷移の履歴にアクセスできなければ、ユーザーが詐欺に遭う可能性があり、二重支出につながるリスクがあります。この問題に対処するために、ワンタイムシールが提案されました。一度しか使用できない特別なオブジェクトを使用することで、二重支払いが発生しないようにすることができ、セキュリティが強化される。ビットコインのUTXO（未使用トランザクション出力）モデルは、ビットコインのコンセンサスメカニズムとネットワークのハッシュ演算によって保護された、ワンタイム封印の最も適した形式であり、RGB資産がビットコインのセキュリティ機能を継承することを可能にします。

暗号的な約束

ワンタイム封印は、ユーザーが状態遷移を明確に認識し、二重支払い攻撃を防ぐために、暗号的な約束と組み合わせる必要があります。約束は、何かが起こり、後で変更できないことを他者に知らせ、検証が必要になるまで具体的な詳細を明らかにしません。これはハッシュ関数を使って実現できる。RGBでは、約束の内容は状態遷移であり、UTXOの支出を通じてRGB資産の受信者に通知される。その後、アセットの受信者は、アセットの支出者によってチェーンを伝わってきた特定のデータに基づいて、約束を検証します。

ワークフロー

RGBはビットコインのコンセンサスを活用し、二重支払いの安全性と検閲への耐性を確保する一方、すべての状態遷移の検証タスクはチェーンを下って委譲され、支払いを受け取るクライアントによってのみ実行されます。

RGB資産の発行者にとって、RGB契約の作成には、特定の情報の約束がTaproot取引条件内のOP_RETURNスクリプトに格納される取引の開始が含まれます。

RGB資産の保有者がそれを使いたい場合、資産の受取人から関連情報を取得し、RGBトランザクションを作成し、このトランザクションの詳細をコミットする必要があります。資産受領者はRGB資産を保管するUTXOが使用されたことに気付くと、ビットコイン取引内の約束でRGB取引の有効性を検証できる。有効性が確認されると、彼らは自信を持ってRGBアセットの受領を認めることができます。

RGB資産の受取人の場合、支払人は、契約の初期状態と状態遷移ルール、送金に使用された各ビットコイン取引、各ビットコイン取引に提出された各RGB取引、各ビットコイン取引の有効性の証拠を提供する必要があります。受信者のクライアントはこのデータを使用してRGBトランザクションの有効性を検証する。このセットアップでは、ビットコインのUTXOがRGB契約の状態のコンテナとして機能する。各RGB契約の移転履歴は有向非循環グラフ（DAG）として表すことができ、RGB資産の受信者は自分の保有に関連する履歴にのみアクセスできますが、他のブランチにはアクセスできません。

長所と短所

軽量検証

ブロックチェーンで必要とされる完全な検証に比べて、RGBプロトコルは検証のコストを大幅に削減します。 最新のステータスを取得するためにすべての履歴ブロックをトラバースする代わりに、ユーザーはトランザクションの有効性を検証するために、受け取った資産に関連する履歴を同期させるだけでよいのです。

この軽量な検証により、ピアツーピアの取引が容易になり、中央集権的なサービスプロバイダーへの依存がさらに減り、分散化が促進されます。

スケーラビリティ

RGBプロトコルは、単一のハッシュ約束でビットコインのセキュリティを継承し、追加のビットコインブロック空間をほとんど消費しないTaprootスクリプトを使用します。これにより、複雑なアセットプログラミングが可能になります。コンテナとしてUTXOを使用することで、RGBプロトコルは自然に並行性をサポートします。異なる転送ブランチ上のRGBアセットは互いにブロックされず、同時に使用することができます。

プライバシー

一般的なプロトコルとは異なり、RGBアセットの受信者だけがアセット転送の履歴にアクセスできます。RGBアセットのトランザクションはビットコインUTXOのトランザクションにリンクされていないため、部外者はビットコインのブロックチェーン上でRGBトランザクションを追跡することができません。

さらに、RGBはブラインド出力をサポートしており、これは支払い者がRGB資産がどのUTXOに支払われるかを判断できないことを意味し、プライバシーと検閲への耐性をさらに強化します。

不利な点

RGB資産が複数回手を変える場合、資産の新しい受取人は、長い送金履歴を検証するためにかなりの検証負担に直面する可能性があり、検証時間が長くなり、取引を迅速に確認する能力が失われる可能性があります。ブロックチェーンで動作するノードでは、常に最新の状態と同期しているため、新しいブロックの受信時に状態遷移を検証するのに必要な時間は効果的に制限されます。

コミュニティは過去の計算を再利用する可能性について議論しており、再帰的ZK証明は状態検証のための一定の時間とサイズを達成するかもしれません。

Rollup

概要

Rollupはイーサリアムのエコシステムにとって最高のスケーリングソリューションです。複数のトランザクションを処理し、それらのトランザクションを実行し、バルクデータとステートコミットメントをメインチェーンにコミットします。これにより、オフチェーンでのトランザクション処理と状態更新が可能になる。スケーラビリティを最大化するために、Rollupは通常この段階で中央集中型のシーケンサーを使用し、メインチェーンによるRollupの状態遷移の検証によって保証されるセキュリティを損なうことなく実行効率を高めます。

イーサリアムエコシステムのロールアップスキームが成熟するにつれ、ビットコインエコシステムもロールアップを模索し始めました。しかし、ビットコインとイーサの主な違いは、オンチェーンロールアップを構築するのに必要な計算を実行するプログラミング能力がないことです。現在、主な焦点はソブリンロールアップとOPロールアップの実装です。

カテゴリ

ロールアップは主に2つのカテゴリに分けることができます：楽観的ロールアップ（Optimistic Rollups）と検証ロールアップ（ZK Rollups）で、主な違いは状態遷移を検証する方法論です。

楽観的ロールアップは楽観的検証を使用し、各バッチが提出された後の論争期間中に誰でもオフチェーンデータを見ることができ、メインチェーンに不正の証明を提出することによって問題のあるバッチに論争し、それによってシーケンサーにペナルティを与えます。論争期間中に有効な不正証明書が提出されなかった場合、その取引バッチは有効とみなされ、メインチェーン上でステータス更新が確認される。

ValidityRollupはValidity Proofを使用して検証されます。シーケンサーはゼロ知識証明アルゴリズムを使用して、トランザクションの各バッチの簡潔な有効性の証明を生成し、バッチの状態遷移が正しいことを証明します。各更新はトランザクション・バッチの有効性の証明をマスター・チェーンに提出する必要があり、マスター・チェーンは証明を検証し、直ちに状態更新を確認する。

Optimistic Rollupは、比較的単純で、メインチェーンの修正が少ないという利点があるが、トランザクションの検証時間が長く（紛争期間による）、データの可用性に対する要件が高いという欠点がある。

Validity Rollupは、トランザクションの検証が高速で、紛争期間に影響されず、トランザクションデータが非公開であることを保証するという利点があるが、ゼロ知識証明の生成と検証にはかなりの計算オーバーヘッドが必要である。証明の生成と検証にはかなりの計算オーバーヘッドを必要とする。

Celestiaはソブリンロールアップの概念も提案しており、ロールアップの取引データは専用のデータ可用性（DA）レイヤーブロックチェーンに投稿され、DAレイヤーはデータの可用性を担当し、ソブリンロールアップ自体は実行と決済を担当します。

ビットコインベースのロールアップは現在初期段階にあり、ビットコインコミュニティは、イーサとの簿記モデルやプログラミング言語の違いにより、イーサの直接複製が困難であるため、革新的なソリューションを積極的に模索しています。

ソブリンロールアップ

2023年3月5日、Rollkitはビットコインのソブリンロールアップをサポートする最初のフレームワークとして発表されました。ソブリンロールアップの構築者は、Rollkitを使ってビットコインの可用性データを公開することができます。

RollkitはOrdinalsに触発され、データを公開するためにTaprootトランザクションを使用しています。パブリックメモリプール標準に準拠したTaprootトランザクションは最大390KBのデータを含むことができますが、マイナーによって直接投稿された非標準のTaprootトランザクションは、ほぼ4MBの任意のデータを含むことができます。

Rollkitは基本的に、ビットコイン上でデータを読み書きするインターフェースを提供し、ビットコインをDAレイヤーに変換するミドルウェアサービスを提供します。

Sovereign Rollupのアイデアは大きな懐疑的な目で見られている。多くの批評家は、ビットコインを単に掲示板として使用するビットコインベースのソブリン・ロールアップは、ビットコインのセキュリティを継承できないと主張した。実際、取引データだけがビットコインに提出され、すべてのユーザーがビットコイン経由で関連データにアクセスし、検証できるようになれば、活動が活発化するだけだ。しかし、セキュリティは主権者であるロールアップ自身によってのみ定義することができ、継承することはできない。さらに、ビットコインのブロックスペースは非常に貴重であり、完全な取引データを提出することは良い決断ではないかもしれません。

OP RollupとValidity Rollup

Bitcoin Layer2プロジェクトの多くはZK Rollupであると主張していますが、本質的にはValidity Proof技術を含むOP Rollupに近いものです。しかし、ビットコインのプログラミング能力は、現在のところ、Validity Proofの直接検証をサポートするには不十分です。

現在、ビットコインには、乗算を直接計算するためのオペコードのセットさえ非常に限られており、妥当性証明の検証には、再帰契約の実装に大きく依存する拡張オペコードが必要です。コミュニティは、OP_CAT、OP_CHECKSIG、OP_TXHASHなどのオプションについて活発に議論している。理想的には、OP_VERIFY_ZKPを追加することで、他の修正なしに問題を解決できるかもしれないが、その可能性は低い。さらに、スタックサイズの制限は、ビットコインスクリプトで有効性の証明を検証する取り組みを妨げており、多くの調査が進行中です。

では、有効性の証明はどのように機能するのでしょうか？ほとんどのプロジェクトは、ステートメントの差分とバルクトランザクションの有効性の証明をinscribe形式でビットコインに公開し、楽観的な検証のためにBitVMを使用します。このシナリオでは、ブリッジオペレーターがフェデレーションとして機能し、ユーザーの入金を管理する。ユーザーがデポジットする前に、フェデレーションはUTXOに事前署名し、デポジットがオペレーターによってのみ合法的に請求できることを保証する。事前署名を取得した後、BTCはN/Nマルチシグネチャータプルートアドレスにロックされます。

ユーザーが引き出しを要求すると、Rollupは有効性の証明とともに引き出しルートをビットコインチェーンに送信します。オペレーターはまず、ユーザーの引き出し要求を満たすためにポケットマネーで支払い、その後BitVMコントラクトが有効性を検証します。各オペレーターが証明が有効であると信じる場合、マルチシグネチャを介してオペレーターに払い戻します。誰かが詐欺があると信じる場合、チャレンジプロセスが開始され、間違った当事者にペナルティが課せられます。

このプロセスは本質的にOP Rollupと同じであり、信頼は1/Nと仮定される - 検証者の1人が正直である限り、プロトコルは安全である。有効性の証明については、ビットコインネットワーク上で検証を容易にすることが目的ではなく、個々のノードが検証しやすくすることが目的です。

<

しかし、このソリューションの技術的な実装は困難に直面するかもしれません。 イーサのOPロールアッププロジェクトのうち、Arbitrumは何年もの開発期間を経て、いまだに不正証明はパーミッションベースのノードによって提出されています。

Bitcoin Covenantのサポートにより、BitVMブリッジの事前署名操作はより効率的に実行できますが、これはまだコミュニティによって合意される必要があります。

セキュリティ属性の観点からは、RollupブロックハッシュをBitcoinに提出することで、Bitcoinは再構成と二重支出に対する耐性を得ますが、Optimistic Bridgeは1/Nのセキュリティ仮定をもたらします。Optimistic Bridgeの検閲耐性もさらに改善されることが期待される。

結論：レイヤー2は万能薬ではない

さまざまなレイヤー2ソリューションを見ていくと、それぞれに限界があることは明らかです。レイヤー2の有効性は、レイヤー1（つまりビットコイン）が特定の信頼前提の下で実行できるかどうかに大きく依存します。

ライトニングネットワークはSegWitのアップグレードとタイムロックがなければうまくセットアップできなかったでしょうし、RGBの約束はTaprootのアップグレードがなければ効率的にコミットできなかったでしょう。...

多くのビットコイン最大化論者は、ビットコインは決して変更されるべきではなく、新しい機能は追加されるべきではなく、すべての欠陥はレイヤー2のソリューションによって対処されるべきだと考えています。レイヤー2は万能薬ではない。より安全で、効率的で、スケーラブルなレイヤー2を構築するためには、より強力なレイヤー1が必要なのです。

次回の記事では、ビットコインのプログラマビリティを強化する試みについて見ていきます。