オフチェーン転送：ビットコイン資産プロトコルの進化の道
TechFlow厳選深潮セレクト
オフチェーン転送：ビットコイン資産プロトコルの進化の道
本稿は、BTCの歴史上に登場した資産プロトコルを振り返ることで、BTC資産プロトコルの将来の発展を探ることを目的としている。
Web3業界の深掘り報道に専念し潮流を洞察序論
BTC上で資産を発行するというアイデアは、常に注目を集めてきた。2011年に登場したカラードコイン（Colored Coins）から最近話題のOrdinalプロトコルに至るまで、BTCコミュニティは常に新しいプレイヤーやコンセンサスを生み出してきたが、長く生き残ったものはほとんどない。しかし、野心的なLightning LabsがTaproot Assets上でのステーブルコイン構築計画を発表し、Tetherもビットコインレイヤー1上でUSDTを発行するためにRGBを選択すると宣言したことで、状況が大きく動き始めた。
これはかつて名を馳せたOmniLayer（Mastercoin）がBTCエコシステム最大の存在ではなくなったことを意味しており、クライアントサイド検証（CSV）型の資産プロトコルが人々の注目を集め始めている。従来のBTC資産プロトコルとの違いは、拡張性を持つ点にある。しかし、これほど多くのBTC資産プロトコルがある中で、それらの違いは何なのか？どう選べばよいのか？また、そこからどのような機会を見つけられるのか？本稿では、BTCの歴史に登場した資産プロトコルを振り返りながら、その将来を探っていく。
カラードコイン：Colored Coins
カラードコインというアイデアは、現在eToroのCEOであるYoni Assia氏が2012年3月27日に「bitcoin 2.X (aka Colored bitcoin)」と題する記事で最初に提唱したものだ。彼はビットコイン自体がHTTPがウェブの基盤であるように、基礎技術として完璧だと考え、それを再利用してカラードコインというトークンプロトコルを設計した。
Yoni Assiaはこの方法により「BTC 2.0経済」を創出しようとした。つまり、あらゆるコミュニティが独自の通貨を発行できる世界である。ビットコインを決済や二重支出防止の基盤として使うという発想は、当時非常に大胆なものだった。
カラードコインはビットコイン上で資産を発行するプロトコルであり、「塗料」を付けて特定の資産として識別できるようにする。こうしてマークされたビットコインは機能的にはそのままビットコインだが、同時に別の価値や資産を象徴するものとなる。だが、これを実際にビットコイン上でどう実現すればよいのか？
2014年7月3日、ChromaWay社は「強化型注文埋め込み着色プロトコル（EPOBC）」を開発した。これは開発者がカラードコインを作成しやすくするもので、OP_RETURN機能を用いたBitcoin Scriptの早期採用例となった。
最終的な実装イメージは以下の通りである：
この実装は非常にシンプルだが、多くの問題も引き起こしている：
1. 同質化トークンと最小バインド値
創世取引においてあるカラードコインに1000 satoshiを割り当てた場合、その最小分割単位は1 satoshiとなる。つまり、この資産は理論上最大1000分割可能ということになる（ただし、ダスト攻撃を防ぐため、当時のsatは通常546 SATに設定されており、後にOrdinalではさらに高くなっている）。
2. 検証の問題
カラードコインの真正性や所有権を確認するには、その資産の創世取引から現在のUTXOまでの一連の履歴を追跡・検証する必要がある。そのため、専用のウォレットやフルノード、さらにはブロックエクスプローラの開発が必要になる。
3. 採掘者による審査リスク
カラードトランザクションはoutputにmetadata情報を書き込むため特徴が明確であり、採掘者がこれを認識して取引を拒否する可能性がある。
カラードコインは実質的に資産追跡システムであり、ビットコインの検証ルールを利用して資産の移転を追跡する。しかし、特定のtxoutがどの資産を表すかを証明するには、資産の起源から現在までの完全な移転チェーンを提示しなければならない。つまり、取引の正当性を検証するには非常に長い証明チェーンが必要になる。この問題に対処するため、当時OP_CHECKCOLORVERIFYという提案もあったが、結局承認されなかった。
暗号業界初のICO：Mastercoin
Mastercoinの概念はJ.R. Willett氏によって提唱された。2012年、彼は「The Second Bitcoin Whitepaper」と題するホワイトペーパーを発表し、既存のビットコインブロックチェーン上に新しい資産やトークンを作成するアイデアを示した。これが後に「MasterCoin」と呼ばれ、その後Omni Layerへと改名された。
Mastercoinプロジェクトは2013年に初期のトークン販売（今日ではICOまたは初期トークン販売と呼ばれる）を行い、数百万ドルを調達した。これは史上初のICOと見なされている。Mastercoinのもっとも有名な応用例はTether（USDT）であり、最も知られた法定通貨ステーブルコインとして、当初はOmni Layer上で発行されていた。
実はMastercoinのアイデアはColored Coinsより早く生まれていたが、ここでは後回しにしている。なぜなら、Colored Coinsに比べてMastercoinの方がより重厚な設計だからである。Mastercoinは完全なノード層を構築しており、スマートコントラクトのような複雑な機能を提供できる。一方、Colored Coinsはよりシンプルで直接的であり、主にUTXOに「色」を付けることで他の資産を表現することに焦点を当てている。
Colored Coinsとの最大の違いは、Mastercoinはチェーン上に資産情報ではなく、さまざまな種類の取引行動のみを記録することにある。代わりに、Mastercoinノードはビットコインのブロックをスキャンして、オフチェーンのデータベースに状態モデルを維持する。
Colored Coinsに比べ、より複雑なロジックを実現できる。また、オンチェーンで状態を記録・検証しないため、取引間で連続性（継続的な着色）を要求しない。
しかし、この複雑なロジックを実現するため、ユーザーはオフチェーンデータベースの状態を信用するか、自らOmni Layerノードを実行して検証する必要がある。
まとめ
MastercoinとColored Coinsの最大の違いは、プロトコルに必要なすべてのデータをオンチェーンで管理せず、BTCのコンセンサスシステムを寄生的に利用して取引の発行と順序付けを行い、状態はオフチェーンデータベースで管理している点にある。
OmniBolt関係者によると、Omni Layerはテザー社に対して新たなUBA（UTXO Based Asset）資産プロトコルを提案中であり、Taprootアップグレードを利用して資産情報をtapleafにエンコードし、条件付き支払いなどの機能を実現する予定だという。また、OmniBoltはStarkをOmniLayerのライトニングネットワークインフラに導入している最中である。
クライアントサイド検証（Client Side Validation）の思想
クライアントサイド検証の概念を理解するには、時間をColored CoinsとMastercoinが登場した翌年の2013年に戻す必要がある。Peter Toddはこの年にDisentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validationという記事を発表した。タイトルからは関係なさそうに見えるが、これがクライアントサイド検証の原点となる啓蒙的思想である。
Peter Toddはビットコインと暗号学の初期研究者の一人であり、ビットコインの動作をより効率的にする方法を常に模索していた。彼はタイムスタンプの概念に基づき、より複雑なクライアントサイド検証の概念を展開した。また、「single use seal」という概念も提唱しており、これは後に言及する。
ここでPeter Toddの思想に沿って、BTCが実際に解決している問題を整理しよう。彼の見解では、BTCは以下の3つの問題を解決している：
-
公開の証明（Proof-of-publication）
公開の証明とは二重支出問題の解決に他ならない。例えばAliceがBobにビットコインを送金しようとするとき、署名付きの取引を作成しても、Bobは物理的にその存在を即座に知ることはできない。そのため、取引を公開する場所が必要であり、誰もがそこから取引を照会できる仕組みが必要となる。
-
取引の順序付け（Order consensus）
コンピュータシステムには我々が日常感じるような物理時間は存在しない。分散システムでは通常、Lamport時計のような分散時計が使われる。これは物理時間の測定ではなく、取引に順序を与えるために用いられる。
-
取引検証（Validation）（任意）
BTCにおける検証は、署名や送金額の正当性のチェックに限られる。しかしPeter Toddは、この検証はBTC上でトークンシステムを構築するうえで必須ではなく、むしろ最適化手段に過ぎないと考える。
ここで読者は先述のOmniLayerを思い出すだろう。OmniLayerは状態計算と検証をBTCに任せていなかったが、それでもBTCのセキュリティを再利用していた。一方、Colored Coinsは状態追跡をBTCに依存していた。この2つの存在は、検証が必ずしもオンチェーンで行われる必要はないことをすでに示している。
クライアントサイド検証はどのように取引を検証するのか？
まず、何を検証する必要があるかを確認しよう：
-
状態（取引ロジックの検証）
-
入力TxInが有効かどうか（二重支出防止）
BTC上で発行された資産は、毎回の取引で関連する全取引履歴を検証しなければ、入力が未使用かつ状態が正しいことを保証できない。これは非常に非効率的である。では、どう改善できるか？
Peter Toddは、検証の焦点を変えることでこのプロセスを簡素化できると考えた。つまり、「出力が二重支出されていないか」を確認するのではなく、「取引入力が公開されており、他の入力と競合していないか」に焦点を当てる。各ブロック内の入力をソートし、Merkle木を使うことで、より効率的な検証が可能になる。なぜなら、検証に必要なのはごく一部のデータだけであり、入力の全履歴を必要としなくなるからだ。
Peter Toddが提唱したcommitment treeの構造は次の通り：
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn
しかし、このようなcommitment treeをチェーン上にどう保存すればよいのか？ここから「ワンタイムシール（single use seal）」の概念が登場する。
ワンタイムシール Single Use Seal
Single use sealはクライアントサイド検証を理解する上で核となる概念の一つであり、貨物コンテナの保護に使われる物理的な一度限りのシールに似ている。Single use sealは一意のオブジェクトであり、あるメッセージに対して正確に一度だけ「閉じる」ことができる。要するに、ワンタイムシールは二重支出を防ぐための抽象的なメカニズムである。
SealProtocolには3つの要素と2つのアクションがある。
基本要素：
-
l： seal（シール）
-
m： message（メッセージ）
-
w： witness（証人）
基本操作：2つの基本操作がある：
-
Close(l,m) → w：メッセージmに対してシールlを閉じ、証人wを生成する。
-
Verify(l,w,m) → bool：シールlがメッセージmに対して閉じられているかを検証する。
single use sealの安全性は、攻撃者が2つの異なるメッセージm1とm2に対して同じシールでVerify関数がtrueを返すような状況を作れないことにある。
まず、「ワンタイムシール（Single-Use Seal）」とは、ある資産やデータが一度しか使われず、ロックされることを保証する概念である。ビットコインの文脈では、これはUTXO（未使用取引出力）が一度しか消費されないことを意味する。つまり、ビットコイン取引の出力はワンタイムシールと見なすことができ、それが別の取引の入力として使われると、そのシールは「破られる」または「使用される」。
BTC上のCSV資産の場合、ビットコイン自体がワンタイムシールの「証人（witness）」の役割を果たす。なぜなら、ビットコイン取引を検証するには、各入力が有効でまだ消費されていないUTXOを参照しているかをチェックする必要があるからだ。もし取引が既に使用されたUTXOを二重に消費しようとした場合、ビットコインのコンセンサスルールとネットワーク上の正直なノードがその取引を拒否する。
もっと簡単にできないか？
single use sealとは、任意のブロックチェーンをデータベースとして使い、あるメッセージのコミットメントを何らかの方法でそこに保存し、それが既に消費されたか、未消費かの状態を管理すること。
そう、それだけのことだ。
以上から、クライアントサイド検証型資産の特徴は以下の通り：
-
オフチェーンデータストレージ：取引履歴、所有権、その他の関連データは大部分がオフチェーンに保存される。これにより、オンチェーンのデータ負荷が大幅に削減され、プライバシーの向上にもつながる。
-
コミットメント機構：資産データはオフチェーンに保存されるが、その変更や移転はコミットメントを通じてオンチェーンに記録される。これにより、オンチェーン取引がオフチェーン状態を参照でき、データの完全性と改ざん防止が確保される。
-
オンチェーンの証人（BTCに限らない）：大部分のデータと検証はオフチェーンで行われるが、オンチェーンに埋め込まれたコミットメントにより、基盤チェーンのセキュリティ（公開の証明、取引の順序付け）を活用できる。
-
検証はクライアント側で実行：検証の大部分はユーザーの端末で行われる。つまり、全ノードがすべての取引を検証する必要はなく、関与する当事者だけがその有効性を検証すればよい。
クライアントサイド検証資産を利用する際の注意点として：
オフチェーンで取引や検証を行う際には、資産の秘密鍵だけでなく、対応する資産の完全なMerkleパスの証明も提示する必要がある。
クライアントサイド検証（CSV）の先駆者：RGB
RGBという概念は2015年以降に、コミュニティの著名人物Giacomo Zucco氏によって提唱された。イーサリアムの台頭とICOの氾濫により、それ以前にビットコイン以外で何かをしようとする試み（MastercoinやColored Coinsなど）が多くなされていた。
Giacomo Zuccoはこれらに失望していた。これらのプロジェクトはビットコインに及ばず、ビットコイン上でトークンを実現するこれまでの方法は不適切だと感じていた。そんな中で彼はPeter Toddに出会い、クライアントサイド検証（Client-Side-Validation）の考えに魅了され、RGBの構想を始めた。
RGBとこれまでの資産プロトコルとの最大の違いは、前述のクライアントサイド検証の特徴に加えて、チューリング完全なコントラクト実行エンジンとしてのVMを追加している点にある。また、コントラクトデータの安全性を保つため、SchemaとInterfaceも設計されている。Schemaはイーサリアムのスマートコントラクトに似ており、コントラクトの内容と機能を宣言する。Interfaceは具体的な機能の実装を担当し、プログラミング言語のinterfaceと同様の役割を果たす。
これらのSchemaはVM実行時に予期しない挙動を制限する。例えばRGB20とRGB21は、それぞれ同質化トークンと非同質化トークンの取引に関する制約を規定している。
RGBのコミットメント機構：ペダーセンハッシュ
コミットメント機構に関して、RGBはペダーセンハッシュを採用している。その利点は、値を明らかにせずにコミットメントを作成できることにある。ペダーセンハッシュを使ってMerkle木を構築することで、内部の値を隠蔽できるプライバシー保護型Merkle木を作成できる。これは匿名暗号通貨プロジェクトなどの特定のプライバシープロトコルに適しているが、CSV資産には必ずしも適していない。後ほどTaproot Assetsとの比較で触れる。
RGBの仮想機械設計：Simplicity → AluVM
RGBの目標は、クライアントサイド検証型資産プロトコルの実現にとどまらず、チューリング完全な仮想マシンとコントラクトプログラミングへの拡張も視野に入れている。初期のRGB設計では、Simplicityというプログラミング言語を使用するとされていた。この言語の特徴は、式の評価時に実行証明が生成され、形式的検証が容易なためバグを回避しやすい点にある。しかし、この言語の開発はうまくいかず、頓挫した。これが当時のRGBプロトコル全体の遅延につながった。最終的にRGBはMaximが開発したAluVMに移行した。AluVMの目標は未定義動作を一切排除することであり、Simplicityの理念に近い。新しいAluVMは将来的にRustの代わりにContractumという言語を使用する予定とされている。
RGBのLayer2拡張方向：ライトニングネットワークかサイドチェーンか？
クライアントサイド検証資産は、オフチェーンで安全に連続取引を行うことが難しい。なぜなら、依然としてL1に依存して取引の発行と順序付けを行う必要があるため、L2拡張スキームがない場合、取引速度はL1のブロック生成速度に制限される。つまり、ビットコイン上で直接RGB取引を行う場合、厳密なセキュリティ要件のもとでは、関連する2つの取引の間隔が最大10分（BTCのブロック生成時間）空く必要がある。これはほとんどの用途で受け入れがたい速度である。
RGBとライトニングネットワーク
ライトニングネットワークの原理は、取引双方がオフチェーンで多数の契約（コミット取引）に署名し、いずれかが契約違反した場合、被害を受けた方がその契約をBTCチェーンに提出して資金を取り戻し、相手を罰する仕組みである。つまり、プロトコルとゲーム理論の設計によってオフチェーン取引の安全性を保証している。
RGBは自身に適したペイメントチャネルの規則を設計することで、独自のライトニングネットワークインフラを構築できる。しかし、ライトニングネットワークの複雑さは非常に高く、その構築は容易ではない。現状、Lightning Labsがこの分野で長年取り組んでおり、LNDは市場で90%以上のシェアを持っている。
RGBのサイドチェーン：Prime
LNP-BPは現在のRGBプロトコルのメンテナーであり、Maxim氏は2023年6月に**Prime**というクライアントサイド検証資産向けの拡張スキームを提案した。彼は既存のサイドチェーンやライトニングネットワークの拡張案は開発が極めて複雑だと批判している。Maximによれば、Prime以外の拡張方法としてはNUCLEUSマルチノードライトニングチャネルやArk/Enigmaチャネルファクトリーがあり、これらは2年以上の開発期間が必要となるが、Primeは1年で完了可能だとする。
Primeは伝統的なブロックチェーン設計ではなく、クライアントサイド検証用に設計されたモジュール型の証明公開レイヤーであり、以下の4つの部分から構成される：
-
タイムスタンプサービス
最短10秒で取引シーケンスを確定。 -
証明
PMT形式でブロックヘッダーとともに生成・公開。 -
ワンタイムシール
抽象的なワンタイムシールプロトコル。二重支出防止を保証できればよい。ビットコイン上ではUTXOにバインド可能で、現行のRGB設計と同様。 -
スマートコントラクトプロトコル
シャーディングコントラクト－RGB（交換可能）
ここから読み取れるのは、RGBの取引確認時間の問題を解決するため、Primeはタイムスタンプサービスを用いてオフチェーン取引を迅速に確定し、取引とIDをブロックに格納する点である。さらに、Prime上の取引証明はPMTでまとめてBTCにチェックポイントのようにアンカーされる。
Taprootに基づくCSV資産プロトコル：Taproot Assets
Taproot AssetsはTaprootを利用したCSV資産プロトコルであり、ビットコインブロックチェーン上でクライアントサイド検証資産を発行できる。これらの資産はライトニングネットワークを通じて即時、大容量、低コストで取引可能となる。Taproot Assetsの核心は、ビットコインネットワークの安全性と安定性、およびライトニングネットワークの速度、拡張性、低コストを活用することにある。このプロトコルはLightning LabsのCTOであるroasbeef氏が設計・開発したものであり、彼は地球上で唯一、ビットコインクライアント（BTCD）とライトニングネットワーククライアント（LND）の両方を主導的に開発した人物であり、BTCに対する理解は極めて深い。
Taproot取引は資産スクリプトのルートハッシュのみを保持するため、外部の観察者はそれがTaproot Assetsに関連しているかどうかを判別しにくい。ハッシュ自体が汎用的であり、任意のデータを表すことができるからだ。Taprootアップグレードにより、ビットコインはスマートコントラクト（TapScript）の能力を得た。この上に、Taproot Assetsの資産エンコーディングはERC20やERC721に類似したトークン定義を実現している。これにより、ビットコインは資産定義機能に加え、スマートコントラクト作成能力も持ち、トークンスマートコントラクト基盤の原型を築いた。
Taproot Assetsのエンコーディング構造は以下の通り：
画像出典：Lightning Labs CTO roasbeef
同様にCSV資産プロトコルであるTaproot Assetsは、RGBに比べて設計がよりシンプルである。また、TaprootアップグレードやPSBTなど、現在のBTCエコシステムの進展を最大限に活用している。Taproot AssetsとRGBのアプリケーション拡張性の最大の違いはVMの実行にあり、Taproot AssetsはBTCネイティブのTaprootScriptVMと同じものを使用している。近年のBTCインフラ研究の多くはTapScriptに基づいているが、BTCのアップグレードが遅いため短期間では適用が難しい。Taproot Assetsはこうした新アイデアの実験場となる可能性が高い。
Taproot AssetsとRGBの違いはどこにあるか？
1. 取引の検証とライトノードの親和性
Taproot Assetsはsum treeの実装により、検証効率と安全性が高い（保持証明だけで状態検証と取引が可能で、入力の全取引履歴を辿る必要がない）。一方、RGBはペダーセンコミットメントを使用しているため、入力の有効性を効率的に検証できず、取引履歴を遡及する必要がある。取引が増えるにつれてこれは非常に重い負担となる。Merkle sumの設計により、Taproot Assetsは容易にライトノード検証を実現しており、これは従来のBTC上資産プロトコルには存在しなかった。
2. 実行VM
Taproot AssetsはTaprootアップグレードに合わせて誕生したため、使用するTaprootScriptVMはTaprootアップグレード後のビットコインに標準搭載されているスクリプト実行エンジンである。また、使用するvPSBTはBTCのPSBTの派生版であり、Taproot Assetsのペイメントチャネル機構が完成すれば、現在のLNDインフラをすべて再利用できる。Lightning Labsの製品群（LNDはライトニングネットワーク市場で90%以上のシェア）も即座に活用可能となる。最近話題のBitVM提案もTaprootScriptに基づいているため、理論的にはこれらの改良がすべてTaproot Assetsを支援できる。
一方、RGBのVMや検証ルール（SCHEMA）は独自体系であり、ある意味で閉じたエコシステムと言える。RGB上での構築は自らのエコ内でのみ機能し、ビットコインエコシステムとの連携は思っているほど緊密ではない。Taprootアップグレードへの追随を例に挙げると、RGBとTaprootアップグレードの唯一の関係は、オンチェーンコミットメントデータをWitnessのTapLeafにエンコードすることだけである。
3. スマートコントラクト
現在のRGB実装では、コントラクトとVMが重点的に設計されている。一方、Taproot Assetsではスマートコントラクトの姿はまだ見えない。ただし、RGBでもグローバルステートの変更を個々の独立コントラクトシャード（UTXO）とどう同期するかは未説明である。また、ペダーセンコミットメントは資産総量の保証には使えるが、他のステートが改ざんされたかどうかをどう検出するかについては、今のところ明確な説明がない。Taproot Assetsも設計はシンプルだが、現時点でのステート保存は資産残高に限られ、他のステートはなく、スマートコントラクトとも言えない。ただしLightning Labsによれば、来年にはスマートコントラクト設計に注力する予定だという。
4. 同期センター
前述のクライアントサイド検証資産の基本原則から、証明（Proof）の保持と秘密鍵の保持は同等に重要である。しかし、証明がユーザーのクライアント側にずっとあると紛失しやすい。どうすればいいか？ Taproot Assetsではuniverseを使ってこの問題を回避できる。Universeは公開監査可能な（MS-SMT）、1つまたは複数の資産をカバーする。通常のTaproot資産ツリーとは異なり、UniverseはTaproot資産をホストしない。代わりに、1つまたは複数の資産履歴のサブセットをコミットする。
RGBではこの役割をStormが担っている。StormはP2P方式でオフチェーンの証明データを同期・保存するが、RGB開発チームの歴史的経緯から、各チームの証明フォーマットは互換性がない。DIBAというRGBエコチームは、この問題を解決するためにcarbonadoを開発すると表明しているが、進捗は不明である。
5. 工学的実装
Taproot Assetsが使用するすべてのライブラリは長年の実績がある。Lightning Labsは自前のビットコインクライアント（BTCD）、ライトニングネットワーククライアント（LND）、および多数のwallet lib実装を持っているからだ。一方、RGBが使用するライブラリの多くは独自定義であり、工業基準から見ると、実装はまだ実験段階にある。
BTC拡張の未来についての考察
ここまで議論してきたように、クライアントサイド検証型資産プロトコルはもはや単なるプロトコルの範疇を超え、計算拡張の方向へと進んでいる。
多くの人が「ビットコインは将来、デジタルゴールドとして存在し、アプリケーションエコは他のチェーンが担う」と言う。しかし、私はこれに異議を唱える。BTCフォーラムでは、多くのalt-coinとその短命な寿命についての議論がある。これらのalt-coinは急速に消え去り、周囲の資本と努力はすべて泡となる。我々はすでにビットコインという強力なコンセンサス基盤を持っている。アプリケーションプロトコルのために新しいL1を構築する必要はない。私たちがすべきことは、この最強のインフラをどう活用するかであり、より長期的な分散化された世界を築くことだ。
より少ないオンチェーン計算、より多くのオンチェーン検証
アプリケーション設計の観点から、ビットコインは早い段階で「オンチェーン計算」ではなく「検証中心」の設計哲学を選んだ（Turing completeness and state for smart contract）。ブロックチェーンの本質はレプリケートされたステートマシンだが、もしチェーンのコンセンサスがオンチェーン計算に置かれているなら、ネットワーク内のすべてのノードがその計算を繰り返すのは、合理的かつ拡張可能なアプローチとは言えない。検証中心であれば、オフチェーン取引の正当性を検証することがBTC拡張にとって最も適した方法かもしれない。
検証がどこで行われるか？ それは重要だ
ビットコイン上でのプロトコル開発者にとって、ビットコインをどのようにキーコンセンサスとして活用し、あるいは検証をオフチェーンに置くか、安全な設計をどう行うかは、プロトコル設計者自身の責任であり、チェーン自体と関連させるべきではない。そのため、検証の実現方法によって、BTCの異なる拡張案が生まれる。
検証の実現視点から、3つの拡張方向がある：
-
検証がオンチェーンで行われる（OP-ZKP）
TaprootScriptVMに直接OP-ZKPを実装すれば、BTC自体にZKP検証能力を持たせることができ、Covenant設計と組み合わせることで、BTCのセキュリティを継承するZk-Rollup拡張案を構築できる。しかし、イーサリアムに検証コントラクトをデプロイするのとは異なり、BTCのアップグレードは遅く、汎用性が低く、今後もアップグレードが必要なop-codeを追加するのは困難である。
-
検証が半オンチェーンで行われる（BitVM）
BitVMの設計上、これは普通の取引ロジック向けではない。Robin linusも、BitVMの将来は各SideChain間の自由なクロスチェーン市場になると述べている。BitVMの案が「半オンチェーン」と言われるのは、検証計算の大部分がオンチェーンで行われず、オフチェーンで行われるからである。しかし、BTCのTaprootを基盤に設計する理由は、必要に応じてTapScriptVMを使って計算検証ができ、理論的にBTCのセキュリティを継承できるようにするためである。この過程で検証信頼チェーンが生まれる。つまり、n人の検証者のうち1人でも正直であればよい、というOptimistic Rollupsの考え方である。
BitVMのオンチェーンオーバーヘッドは巨大だが、ZK詐欺証明を使って効率を上げられるか？答えは否定的である。なぜならZK詐欺証明の実現は、チェーン上でZKPを検証できることが前提であり、それは再びOP-ZKP案の難しさに戻ってしまうからだ。
-
検証がオフチェーンで行われる（Client-Side-Validation, Lightning Network）
検証が完全にオフチェーンで行われる場合、前述のCSV資産プロトコルやライトニングネットワークが該当する。CSV設計では、共謀による改ざんを完全に防ぐことはできない。できるのは、暗号学とプロトコル設計で悪意のある共謀の影響範囲を制限し、利益を出せないようにすることである。
オフチェーン検証の利点と欠点はどちらも非常に明確である。利点はオンチェーンリソースの占有が極めて少なく、拡張性が非常に高いこと。欠点はBTCのセキュリティをほぼ完全に再利用できないため、オフチェーンで行える取引タイプや方法に大きな制限がかかる点である。また、オフチェーン検証はデータがすべてオフチェーンにあり、ユーザー自身が管理することを意味するため、ソフトウェア実行環境のセキュリティと安定性に高い要求が課される。
拡張の進化トレンド
現在、イーサリアムで流行しているLayer2は、パラダイムとしてLayer1がLayer2の計算妥当性を検証するものであり、状態計算をLayer2に押し下げつつ、検証はLayer1に残している。将来は検証計算もさらにオフチェーンに押し下げることで、現在のブロックチェーンインフラの性能をさらに解放できるだろう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@wooooer
