サマリー:
Delphi Digitalは最近、「ビットコインプログラマビリティの夜明け: ロールアップの道を開く」と題されたレポートを発表しました。このレポートでは、ビットコインロールアップに関連する主要な概念、BitVMスイート、OP_CATとCovenantの制限、ビットコインエコシステムのDAレイヤー、ブリッジ、およびBitVMを使用した4つの主要なLayer 2ソリューションであるBitlayer、Citrea、Yona、Bobについて概説しています。このレポートはビットコインLayer 2テクノロジーの概要を提供していますが、かなり一般的で詳細な説明が欠けているため、やや理解しにくいです。Geek Web3はDelphiのレポートを拡張し、BitVMなどのテクノロジーをより体系的に理解できるように支援しています。
Bitlayerの研究チームとBitVM中国コミュニティと協力して、「BTCにアプローチする」シリーズを立ち上げます。このシリーズは、BitVM、OP_CAT、ビットコインクロスチェーンブリッジなどの重要なトピックに焦点を当て、より広い観客にビットコインレイヤー2技術を解説し、さらなる愛好家に道を開くことを目指しています。
数ヶ月前、ZeroSyncのリーダーであるRobin Linusが、「BitVM: Bitcoin上で何でも計算する」と題した記事を公開し、BitVMのコンセプトを公式に紹介し、Bitcoinレイヤー2テクノロジーを推進しました。これは、Bitcoinエコシステムにおける最も革新的なイノベーションの1つと見なされており、Bitcoinレイヤー2スペースでの大きな関心と活動を引き起こしました。Bitlayer、Citrea、BOBなどの注目すべきプロジェクトを引き付け、市場に新しいエネルギーをもたらしました。その後、さらに多くの研究者がBitVMの改善に参加し、BitVM1、BitVM2、BitVMX、BitSNARKなどのいくつかのイテレーションバージョンが生まれました。一般的な概要は次のとおりです:
現在、BitVM関連の開発者エコシステムの構築がますます明確になり、周辺ツールの繰り返し改善も肉眼で見ることができます。昨年と比較して、今日のBitVMエコシステムは、初期の「空中の城」から「ぼんやりと見える」に変わり、ますます多くの人々を引きつけています。より多くの開発者やVCがビットコインエコシステムに殺到しています。
ほとんどの人にとって、BitVMやビットコインレイヤー2に関連する専門用語を理解することは簡単ではありません。これには、特にビットコインスクリプトやTaprootの基礎知識を体系的に把握する必要があります。既存のオンラインリソースは、しばしば長すぎて関係のない詳細でいっぱいであるか、あるいは簡潔すぎて理解しにくいことが多いです。私たちは、明確で簡潔な言葉を使ってこれらの問題を解決し、より多くの人々がビットコインレイヤー2の基本的な概念を理解し、BitVMシステムを包括的に理解するのに役立てることを目指しています。
MATTとコミットメント:BitVMのコアコンセプト
BitVMの中核コンセプトは、MATT(Merkleize All The Thingsの略)を中心としています。この手法は、複雑なプログラムの実行を表すためにMerkle Tree(階層的なデータ保管構造)を使用します。これにより、Bitcoinネットワーク上でネイティブな詐欺証明の検証が可能となります。MATTは複雑なプログラムとそのデータ処理活動の詳細を捉えることができますが、これらの大規模なデータはBitcoinブロックチェーンに直接公開されません。代わりに、MATT手法はこれらのデータをオフチェーンのMerkleツリーに格納し、ブロックチェーンにはMerkleルート(Merkleツリーの最上位の要約)のみを公開します。Merkleツリーには主に3つの主要なコンポーネントが含まれています。
(Merkle Treeの簡単なスキーマ図。図の下部にある8つのデータ断片からMerkle Rootが多層ハッシングを通じて計算されます)
MATTスキームでは、チェーン上には非常に小さなMerkle Rootのみが保存され、Merkle Treeに含まれる完全なデータセットはオフチェーンに保存されます。これは「コミットメント」と呼ばれるアイデアを使用しています。ここでは「コミットメント」が何であるかについて説明します。
約束は簡潔な声明のようなものであり、大量のデータを圧縮した後に得られる「指紋」として理解することができます。一般的に、チェーン上で「約束」を発行する人物は、オフチェーンに保管されている特定のデータが正確であると主張します。これらのオフチェーンデータは簡潔な声明に対応すべきであり、この声明が「約束」です。
ある時点で、データのハッシュはデータ自体への「コミットメント」として使用されることがあります。他のコミットメントスキームには、KZGコミットメントやMerkle Treeなどがあります。 Layer2の通常の不正証明プロトコルでは、データの発行者はオフチェーンで完全なデータセットを公開し、オンチェーンでデータセットの公開のコミットメントを行います。オフチェーンのデータセットに無効なデータが見つかった場合、オンチェーンのデータコミットメントが問題になります。
コミットメントを通じて、第2層は大量のデータを圧縮し、ビットコインチェーン上でその「コミットメント」だけを公開することができます。もちろん、オフチェーンで公開された完全なデータセットが外部から観察されることも必要です。
現在、BitVM0、BitVM1、BitVM2、およびBitVMXなどの主要なBitVMスキームはすべて類似の抽象構造に従っています。
Bitcoinを理解することは、単純な取引でさえ、いくつかの重要な概念が関わるため、Ethereumよりも理解するのが難しいことがあります。これにはUTXO(未使用取引出力)、ロックスクリプト(またはScriptPubKeyとも呼ばれる)、およびアンロックスクリプト(またはScriptSigとも呼ばれる)が含まれます。まず、これらの基本的な概念を解説しましょう。
(ビットコインスクリプトコードのサンプルは、高水準言語と比較して下位レベルのオペコードで構成されています)イーサリアムの資産表現方法は、AlipayやWeChatのようなシステムに類似しており、各取引は単純に異なる口座の残高を調整します。この口座ベースのアプローチでは、資産残高を単なる口座に関連付けられた数値として扱います。一方、ビットコインの資産表現は、金と取引するのに似ており、各金塊(UTXO)に所有者が付いています。ビットコイン取引は古いUTXOを実質的に破壊し、新しいUTXOを作成し、その過程で所有権が変わります。ビットコインのUTXOには2つの主要なコンポーネントが含まれています:
(アンロックスクリプトはロックスクリプトと一致する必要があります)ビットコイン取引では、各取引は複数のインプットとアウトプットで構成されています。各インプットはアンロックするUTXOを指定し、それを行うためのアンロックスクリプトを提供し、それによってUTXOをアンロックして破壊します。取引のアウトプットは新しく作成されたUTXOを示し、関連するロックスクリプトを公開的に表示します。たとえば、取引のインプットでは、他の人が送った複数のUTXOをアンロックして破壊し、それによってSamであることを証明します。その後、複数の新しいUTXOを作成し、将来的にxxxがそれらをアンロックできるように指定します。
具体的には、トランザクションの入力データでは、アンロックする意図のあるUTXOを宣言し、これらのUTXOデータの「格納場所」を指定する必要があります。 BitcoinとEthereumは、これを異なる方法で処理していることを理解することが重要です。 Ethereumは契約口座と外部所有口座(EOA)を使用してデータを格納し、これらの口座の下に数字として資産残高が記録されます。 すべての情報は、「ワールドステート」と呼ばれるデータベースに格納されます。 トランザクションが発生すると、「ワールドステート」は特定の口座の残高を直接更新し、データを簡単に特定できるようにします。 対照的に、Bitcoinには「ワールドステート」がありません。 代わりに、資産データは未使用のUTXOとして前のブロック全体に分散され、各トランザクションの出力ごとに個別に格納されています。
特定のUTXOをアンロックしたい場合は、UTXO情報が過去のどのトランザクションのアウトプットに存在するかを示し、トランザクションのID(ハッシュ)を表示する必要があります。ビットコインノードにそれを過去の履歴から探してもらいます。特定のアドレスのビットコイン残高を問い合わせたい場合は、開示されたUTXOを見つけるために最初からすべてのブロックをトラバースする必要があります。
通常、Bitcoinウォレットを使用すると、特定のアドレスが所有するBitcoin残高をすばやく確認できます。これは、ウォレットサービス自体がブロックをスキャンしてすべてのアドレスをインデックス化しているため、迅速にクエリを行いやすくなっているからです。
(UTXOを他の人に譲渡するトランザクションを作成する場合は、そのUTXOが属するトランザクションハッシュ/IDを参照して、ビットコインのトランザクション履歴でそのUTXOの場所を指定する必要があります。興味深いことに、ビットコインの取引結果はオフチェーンで計算されます。ユーザーがローカルデバイスでトランザクションを生成する場合、トランザクションの出力を効果的に計算するために、すべての入力と出力を事前に作成する必要があります。その後、トランザクションはビットコインネットワークにブロードキャストされ、ノードによって検証され、ブロックチェーンに追加されます。この「オフチェーン計算 - オンチェーン検証」モデルは、イーサリアムのモデルとはまったく異なります。イーサリアムでは、トランザクションの入力パラメータを提供するだけで、トランザクションの結果はイーサリアムノードによって計算され、出力されます。さらに、UTXOのロックスクリプトはカスタマイズすることができます。UTXOを「特定のビットコインアドレスの所有者がロック解除可能」に設定し、所有者にデジタル署名と公開鍵(P2PKH)の提供を要求することができます。P2SH(Pay-to-Script-Hash)トランザクションでは、UTXOのロックスクリプトにスクリプトハッシュを追加することができます。このハッシュに対応するスクリプトを送信し、スクリプトで指定された条件を満たすことができる人は誰でもUTXOのロックを解除できます。BitVMが依存しているTaprootスクリプトは、 P2SHと同様の機能を使用しています。
ビットコインスクリプトのトリガーメカニズムを理解するために、「公開鍵ハッシュへの支払い」を表すP2PKHの例から始めます。この設定では、UTXOのロックスクリプトには公開鍵ハッシュが含まれており、ロックを解除するには、対応する公開鍵を提供する必要があります。このメカニズムは、ビットコイン取引の標準的なプロセスと一致しています。このコンテキストでは、ビットコインノードは、ロック解除スクリプトの公開鍵がロックスクリプトで指定された公開鍵ハッシュと一致することを確認する必要があります。基本的には、ユーザーから提供された「キー」がUTXOによって設定された「ロック」に適合しているかどうかをチェックします。より詳細に説明すると、P2PKHスキームでは、ビットコインノードがトランザクションを受信すると、ユーザーのロック解除スクリプト(ScriptSig)とロック解除するUTXOのロックスクリプト(ScriptPubKey)を組み合わせ、この結合スクリプトをビットコインスクリプト実行環境で実行します。以下の図は、実行前の連結された結果を示しています。
読者の皆さんはBTCスクリプトの実行環境に馴染みがないかもしれませんので、簡単に紹介しましょう。ビットコインスクリプトは、データとオペコードの2つの要素で構成されています。これらの要素は、左から右に順番にスタックにプッシュされ、指定されたロジックに従って実行され、最終結果が生成されます (スタックとは何かの説明については、読者は ChatGPT を参照できます)。上記の例では、左側は、デジタル署名と公開キーを含む、ユーザーから提供されたロック解除スクリプト (ScriptSig) を示しています。右側はロックスクリプト(ScriptPubKey)で、UTXOの生成時にUTXO作成者が設定した一連のオペコードとデータが含まれています(一般的な考え方を理解すれば十分で、各オペコードの意味を掘り下げる必要はありません)。右側のロック スクリプトのオペコード (DUP、HASH160、EQUALVERIFY など) は、左側のロック解除スクリプトの公開キーをハッシュし、ロック スクリプトの事前設定された公開キー ハッシュと比較します。これらが一致する場合は、ロック解除スクリプトの公開キーがロックスクリプトの公開キーハッシュと一致することを確認し、最初の検証に合格します。ただし、ロックスクリプトの内容がブロックチェーン上で公開されているため、公開鍵のハッシュを誰でも見ることができるという問題があります。したがって、誰でも対応する公開鍵を提出し、権限のある人物であると偽って主張する可能性があります。これに対処するために、システムは、公開鍵と公開鍵ハッシュを検証した後、トランザクション・イニシエーターが実際に公開鍵を制御しているかどうかも検証する必要があり、これにはデジタル署名の検証が含まれます。この検証は、ロック・スクリプトの CHECKSIG オペコードによって処理されます。要約すると、P2PKHスキームでは、トランザクションイニシエータのロック解除スクリプトに公開鍵とデジタル署名を含める必要があります。公開鍵は、ロック・スクリプトで指定された公開鍵ハッシュと一致する必要があり、デジタル署名は正しい必要があります。UTXOを正常にアンロックするには、これらの条件を満たす必要があります。
(これはダイナミックなイラストです:P2PKHスキームのBitcoinアンロックスクリプトの図解
ソース:https://learnmeabitcoin.com/technical/script)
ビットコインネットワークは、Pay to Public Key/Public Key Hashを超えて、P2SH(Pay to Script Hash)などさまざまなトランザクションタイプをサポートしていることに注意することが重要です。トランザクションの具体的なタイプは、UTXOが作成されるときにロッキングスクリプトがどのように構成されているかに依存します。
P2SHスキームの下では、ロックスクリプトにScript Hashを事前設定でき、アンロックスクリプトはこのScript Hashに対応する完全なスクリプト内容を提供する必要があります。 Bitcoinノードはこのスクリプトを実行し、マルチ署名検証ロジックが含まれていれば、Bitcoinブロックチェーン上でマルチ署名ウォレットを効果的に有効にします。 P2SHスキームでは、UTXO作成者は将来UTXOをアンロックする人にScript Hashに対応するスクリプト内容について通知する必要があります。 両当事者がスクリプト内容を把握している限り、マルチ署名以上の複雑なビジネスロジックを実装できます。 また、Bitcoinブロックチェーンは直接UTXOがどのアドレスにリンクされているかを記録しません。 代わりに、どのUTXOがどの公開鍵ハッシュまたはスクリプトハッシュによってアンロックできるかを記録します。 ただし、公開鍵ハッシュまたはスクリプトハッシュから対応するアドレス(ウォレットインタフェースに表示される一連の文字列であるような意味不明なもの)を迅速に導出できます。
特定のアドレスに関連付けられたビットコインの量をブロックエクスプローラやウォレットインターフェースで表示できる理由は、これらのサービスがブロックチェーンデータを解析して解釈するためです。彼らはすべてのブロックをスキャンし、ロックスクリプトで宣言された公開鍵ハッシュまたはスクリプトハッシュに基づいて、対応する「アドレス」を計算します。これにより、そのアドレスに関連付けられたビットコインの量を表示できるようになります。
P2SHを理解することで、BitVMの重要なコンポーネントであるTaprootに近づくことができます。ただし、Taprootに飛び込む前に、WitnessおよびSegregated Witness(SegWit)の概念を把握することが重要です。ロック解除およびロックスクリプト、またUTXOロック解除プロセスを見直すと、取引のデジタル署名がロック解除スクリプトに含まれているという問題が浮かび上がります。この署名を生成する際、ロック解除スクリプト自体は署名を生成するデータの一部にはなりません(署名自体は使用されるパラメータに含まれないため)。
したがって、デジタル署名は、アンロックスクリプト以外の取引データの一部しかカバーすることができず、それにより取引データ全体を完全に保護することはできません。これにより、中間者がアンロックスクリプトをわずかに変更して署名の検証に影響を与えることなく、脆弱性が生じます。たとえば、Bitcoinノードやマイニングプールがアンロックスクリプトに追加データを挿入する可能性があります。この変更は検証や取引結果に影響を与えないものの、取引データをわずかに変更し、それにより計算される取引ハッシュ/取引IDも変更されます。この問題は取引の可変性として知られています。
これに問題があるのは、お互いに依存する複数の連続した取引を開始する予定の場合(たとえば、取引3は取引2の出力を参照し、取引2は取引1の出力を参照する)、後続の取引は前の取引のハッシュを参照する必要があります。 マイニングプールやビットコインノードなどの中間者は、アンロックスクリプトにわずかな修正を加えることで、取引ハッシュをブロックチェーンに記録される際に予期したものとは異なるものにすることができます。
この不一致は、相互依存トランザクションの事前に計画されたシーケンスを無効にする可能性があります。この問題は、DLCブリッジやBitVM2の文脈で特に関連しており、順次関連するトランザクションのバッチが構築されるため、このようなシナリオが非常に一般的です。
簡単に言えば、取引の可変性の問題は、取引ID/ハッシュの計算にアンロックスクリプトからのデータが含まれているため発生します。ビットコインノードなどの仲介者は、アンロックスクリプトをわずかに変更することができ、それによりユーザーの期待と一致しない取引IDが生成されます。この問題は、ビットコインの初期設計上の制限に起因しています。セグリゲーテッドウィットネス(SegWit)アップグレードは、取引IDをアンロックスクリプトから切り離すことでこの問題に対処します。SegWitにより、取引ハッシュの計算にはアンロックスクリプトのデータが含まれなくなります。SegWitの下でのUTXOロックスクリプトは、「OP_0」オペコードでマーカーとして始まり、対応するアンロックスクリプトはSigScriptからWitnessに名前が変更されます。
分離された証人(SegWit)ルールに準拠することにより、トランザクション展性の問題は効果的に解決され、ビットコインノードによってトランザクションデータが改ざんされるという懸念が排除されます。P2WSH(Pay to Witness Script Hash)の機能は、P2SH(Pay to Script Hash)と基本的に同じです。UTXOロックスクリプトでスクリプトハッシュをプリセットすることができ、ロック解除スクリプトを送信した人は、対応するスクリプトコンテンツをチェーンに提供して実行します。ただし、必要なスクリプトの内容が非常に大きく、多くのコードが含まれている場合、従来の方法ではスクリプト全体をビットコインブロックチェーンに送信できない場合があります(ブロックサイズの制限のため)。そのような場合、Taprootの出番です。Taprootは、オンチェーンのスクリプトコンテンツの圧縮を可能にし、より大きなスクリプトの処理を可能にします。BitVMはTaprootを活用して、より複雑なソリューションを構築します。次回の「BTCに近づく」連載では、Taprootやプリシグネチャーなど、BitVMに関する高度な技術について詳しく解説していきます。ご期待ください!
サマリー:
Delphi Digitalは最近、「ビットコインプログラマビリティの夜明け: ロールアップの道を開く」と題されたレポートを発表しました。このレポートでは、ビットコインロールアップに関連する主要な概念、BitVMスイート、OP_CATとCovenantの制限、ビットコインエコシステムのDAレイヤー、ブリッジ、およびBitVMを使用した4つの主要なLayer 2ソリューションであるBitlayer、Citrea、Yona、Bobについて概説しています。このレポートはビットコインLayer 2テクノロジーの概要を提供していますが、かなり一般的で詳細な説明が欠けているため、やや理解しにくいです。Geek Web3はDelphiのレポートを拡張し、BitVMなどのテクノロジーをより体系的に理解できるように支援しています。
Bitlayerの研究チームとBitVM中国コミュニティと協力して、「BTCにアプローチする」シリーズを立ち上げます。このシリーズは、BitVM、OP_CAT、ビットコインクロスチェーンブリッジなどの重要なトピックに焦点を当て、より広い観客にビットコインレイヤー2技術を解説し、さらなる愛好家に道を開くことを目指しています。
数ヶ月前、ZeroSyncのリーダーであるRobin Linusが、「BitVM: Bitcoin上で何でも計算する」と題した記事を公開し、BitVMのコンセプトを公式に紹介し、Bitcoinレイヤー2テクノロジーを推進しました。これは、Bitcoinエコシステムにおける最も革新的なイノベーションの1つと見なされており、Bitcoinレイヤー2スペースでの大きな関心と活動を引き起こしました。Bitlayer、Citrea、BOBなどの注目すべきプロジェクトを引き付け、市場に新しいエネルギーをもたらしました。その後、さらに多くの研究者がBitVMの改善に参加し、BitVM1、BitVM2、BitVMX、BitSNARKなどのいくつかのイテレーションバージョンが生まれました。一般的な概要は次のとおりです:
現在、BitVM関連の開発者エコシステムの構築がますます明確になり、周辺ツールの繰り返し改善も肉眼で見ることができます。昨年と比較して、今日のBitVMエコシステムは、初期の「空中の城」から「ぼんやりと見える」に変わり、ますます多くの人々を引きつけています。より多くの開発者やVCがビットコインエコシステムに殺到しています。
ほとんどの人にとって、BitVMやビットコインレイヤー2に関連する専門用語を理解することは簡単ではありません。これには、特にビットコインスクリプトやTaprootの基礎知識を体系的に把握する必要があります。既存のオンラインリソースは、しばしば長すぎて関係のない詳細でいっぱいであるか、あるいは簡潔すぎて理解しにくいことが多いです。私たちは、明確で簡潔な言葉を使ってこれらの問題を解決し、より多くの人々がビットコインレイヤー2の基本的な概念を理解し、BitVMシステムを包括的に理解するのに役立てることを目指しています。
MATTとコミットメント:BitVMのコアコンセプト
BitVMの中核コンセプトは、MATT(Merkleize All The Thingsの略)を中心としています。この手法は、複雑なプログラムの実行を表すためにMerkle Tree(階層的なデータ保管構造)を使用します。これにより、Bitcoinネットワーク上でネイティブな詐欺証明の検証が可能となります。MATTは複雑なプログラムとそのデータ処理活動の詳細を捉えることができますが、これらの大規模なデータはBitcoinブロックチェーンに直接公開されません。代わりに、MATT手法はこれらのデータをオフチェーンのMerkleツリーに格納し、ブロックチェーンにはMerkleルート(Merkleツリーの最上位の要約)のみを公開します。Merkleツリーには主に3つの主要なコンポーネントが含まれています。
(Merkle Treeの簡単なスキーマ図。図の下部にある8つのデータ断片からMerkle Rootが多層ハッシングを通じて計算されます)
MATTスキームでは、チェーン上には非常に小さなMerkle Rootのみが保存され、Merkle Treeに含まれる完全なデータセットはオフチェーンに保存されます。これは「コミットメント」と呼ばれるアイデアを使用しています。ここでは「コミットメント」が何であるかについて説明します。
約束は簡潔な声明のようなものであり、大量のデータを圧縮した後に得られる「指紋」として理解することができます。一般的に、チェーン上で「約束」を発行する人物は、オフチェーンに保管されている特定のデータが正確であると主張します。これらのオフチェーンデータは簡潔な声明に対応すべきであり、この声明が「約束」です。
ある時点で、データのハッシュはデータ自体への「コミットメント」として使用されることがあります。他のコミットメントスキームには、KZGコミットメントやMerkle Treeなどがあります。 Layer2の通常の不正証明プロトコルでは、データの発行者はオフチェーンで完全なデータセットを公開し、オンチェーンでデータセットの公開のコミットメントを行います。オフチェーンのデータセットに無効なデータが見つかった場合、オンチェーンのデータコミットメントが問題になります。
コミットメントを通じて、第2層は大量のデータを圧縮し、ビットコインチェーン上でその「コミットメント」だけを公開することができます。もちろん、オフチェーンで公開された完全なデータセットが外部から観察されることも必要です。
現在、BitVM0、BitVM1、BitVM2、およびBitVMXなどの主要なBitVMスキームはすべて類似の抽象構造に従っています。
Bitcoinを理解することは、単純な取引でさえ、いくつかの重要な概念が関わるため、Ethereumよりも理解するのが難しいことがあります。これにはUTXO(未使用取引出力)、ロックスクリプト(またはScriptPubKeyとも呼ばれる)、およびアンロックスクリプト(またはScriptSigとも呼ばれる)が含まれます。まず、これらの基本的な概念を解説しましょう。
(ビットコインスクリプトコードのサンプルは、高水準言語と比較して下位レベルのオペコードで構成されています)イーサリアムの資産表現方法は、AlipayやWeChatのようなシステムに類似しており、各取引は単純に異なる口座の残高を調整します。この口座ベースのアプローチでは、資産残高を単なる口座に関連付けられた数値として扱います。一方、ビットコインの資産表現は、金と取引するのに似ており、各金塊(UTXO)に所有者が付いています。ビットコイン取引は古いUTXOを実質的に破壊し、新しいUTXOを作成し、その過程で所有権が変わります。ビットコインのUTXOには2つの主要なコンポーネントが含まれています:
(アンロックスクリプトはロックスクリプトと一致する必要があります)ビットコイン取引では、各取引は複数のインプットとアウトプットで構成されています。各インプットはアンロックするUTXOを指定し、それを行うためのアンロックスクリプトを提供し、それによってUTXOをアンロックして破壊します。取引のアウトプットは新しく作成されたUTXOを示し、関連するロックスクリプトを公開的に表示します。たとえば、取引のインプットでは、他の人が送った複数のUTXOをアンロックして破壊し、それによってSamであることを証明します。その後、複数の新しいUTXOを作成し、将来的にxxxがそれらをアンロックできるように指定します。
具体的には、トランザクションの入力データでは、アンロックする意図のあるUTXOを宣言し、これらのUTXOデータの「格納場所」を指定する必要があります。 BitcoinとEthereumは、これを異なる方法で処理していることを理解することが重要です。 Ethereumは契約口座と外部所有口座(EOA)を使用してデータを格納し、これらの口座の下に数字として資産残高が記録されます。 すべての情報は、「ワールドステート」と呼ばれるデータベースに格納されます。 トランザクションが発生すると、「ワールドステート」は特定の口座の残高を直接更新し、データを簡単に特定できるようにします。 対照的に、Bitcoinには「ワールドステート」がありません。 代わりに、資産データは未使用のUTXOとして前のブロック全体に分散され、各トランザクションの出力ごとに個別に格納されています。
特定のUTXOをアンロックしたい場合は、UTXO情報が過去のどのトランザクションのアウトプットに存在するかを示し、トランザクションのID(ハッシュ)を表示する必要があります。ビットコインノードにそれを過去の履歴から探してもらいます。特定のアドレスのビットコイン残高を問い合わせたい場合は、開示されたUTXOを見つけるために最初からすべてのブロックをトラバースする必要があります。
通常、Bitcoinウォレットを使用すると、特定のアドレスが所有するBitcoin残高をすばやく確認できます。これは、ウォレットサービス自体がブロックをスキャンしてすべてのアドレスをインデックス化しているため、迅速にクエリを行いやすくなっているからです。
(UTXOを他の人に譲渡するトランザクションを作成する場合は、そのUTXOが属するトランザクションハッシュ/IDを参照して、ビットコインのトランザクション履歴でそのUTXOの場所を指定する必要があります。興味深いことに、ビットコインの取引結果はオフチェーンで計算されます。ユーザーがローカルデバイスでトランザクションを生成する場合、トランザクションの出力を効果的に計算するために、すべての入力と出力を事前に作成する必要があります。その後、トランザクションはビットコインネットワークにブロードキャストされ、ノードによって検証され、ブロックチェーンに追加されます。この「オフチェーン計算 - オンチェーン検証」モデルは、イーサリアムのモデルとはまったく異なります。イーサリアムでは、トランザクションの入力パラメータを提供するだけで、トランザクションの結果はイーサリアムノードによって計算され、出力されます。さらに、UTXOのロックスクリプトはカスタマイズすることができます。UTXOを「特定のビットコインアドレスの所有者がロック解除可能」に設定し、所有者にデジタル署名と公開鍵(P2PKH)の提供を要求することができます。P2SH(Pay-to-Script-Hash)トランザクションでは、UTXOのロックスクリプトにスクリプトハッシュを追加することができます。このハッシュに対応するスクリプトを送信し、スクリプトで指定された条件を満たすことができる人は誰でもUTXOのロックを解除できます。BitVMが依存しているTaprootスクリプトは、 P2SHと同様の機能を使用しています。
ビットコインスクリプトのトリガーメカニズムを理解するために、「公開鍵ハッシュへの支払い」を表すP2PKHの例から始めます。この設定では、UTXOのロックスクリプトには公開鍵ハッシュが含まれており、ロックを解除するには、対応する公開鍵を提供する必要があります。このメカニズムは、ビットコイン取引の標準的なプロセスと一致しています。このコンテキストでは、ビットコインノードは、ロック解除スクリプトの公開鍵がロックスクリプトで指定された公開鍵ハッシュと一致することを確認する必要があります。基本的には、ユーザーから提供された「キー」がUTXOによって設定された「ロック」に適合しているかどうかをチェックします。より詳細に説明すると、P2PKHスキームでは、ビットコインノードがトランザクションを受信すると、ユーザーのロック解除スクリプト(ScriptSig)とロック解除するUTXOのロックスクリプト(ScriptPubKey)を組み合わせ、この結合スクリプトをビットコインスクリプト実行環境で実行します。以下の図は、実行前の連結された結果を示しています。
読者の皆さんはBTCスクリプトの実行環境に馴染みがないかもしれませんので、簡単に紹介しましょう。ビットコインスクリプトは、データとオペコードの2つの要素で構成されています。これらの要素は、左から右に順番にスタックにプッシュされ、指定されたロジックに従って実行され、最終結果が生成されます (スタックとは何かの説明については、読者は ChatGPT を参照できます)。上記の例では、左側は、デジタル署名と公開キーを含む、ユーザーから提供されたロック解除スクリプト (ScriptSig) を示しています。右側はロックスクリプト(ScriptPubKey)で、UTXOの生成時にUTXO作成者が設定した一連のオペコードとデータが含まれています(一般的な考え方を理解すれば十分で、各オペコードの意味を掘り下げる必要はありません)。右側のロック スクリプトのオペコード (DUP、HASH160、EQUALVERIFY など) は、左側のロック解除スクリプトの公開キーをハッシュし、ロック スクリプトの事前設定された公開キー ハッシュと比較します。これらが一致する場合は、ロック解除スクリプトの公開キーがロックスクリプトの公開キーハッシュと一致することを確認し、最初の検証に合格します。ただし、ロックスクリプトの内容がブロックチェーン上で公開されているため、公開鍵のハッシュを誰でも見ることができるという問題があります。したがって、誰でも対応する公開鍵を提出し、権限のある人物であると偽って主張する可能性があります。これに対処するために、システムは、公開鍵と公開鍵ハッシュを検証した後、トランザクション・イニシエーターが実際に公開鍵を制御しているかどうかも検証する必要があり、これにはデジタル署名の検証が含まれます。この検証は、ロック・スクリプトの CHECKSIG オペコードによって処理されます。要約すると、P2PKHスキームでは、トランザクションイニシエータのロック解除スクリプトに公開鍵とデジタル署名を含める必要があります。公開鍵は、ロック・スクリプトで指定された公開鍵ハッシュと一致する必要があり、デジタル署名は正しい必要があります。UTXOを正常にアンロックするには、これらの条件を満たす必要があります。
(これはダイナミックなイラストです:P2PKHスキームのBitcoinアンロックスクリプトの図解
ソース:https://learnmeabitcoin.com/technical/script)
ビットコインネットワークは、Pay to Public Key/Public Key Hashを超えて、P2SH(Pay to Script Hash)などさまざまなトランザクションタイプをサポートしていることに注意することが重要です。トランザクションの具体的なタイプは、UTXOが作成されるときにロッキングスクリプトがどのように構成されているかに依存します。
P2SHスキームの下では、ロックスクリプトにScript Hashを事前設定でき、アンロックスクリプトはこのScript Hashに対応する完全なスクリプト内容を提供する必要があります。 Bitcoinノードはこのスクリプトを実行し、マルチ署名検証ロジックが含まれていれば、Bitcoinブロックチェーン上でマルチ署名ウォレットを効果的に有効にします。 P2SHスキームでは、UTXO作成者は将来UTXOをアンロックする人にScript Hashに対応するスクリプト内容について通知する必要があります。 両当事者がスクリプト内容を把握している限り、マルチ署名以上の複雑なビジネスロジックを実装できます。 また、Bitcoinブロックチェーンは直接UTXOがどのアドレスにリンクされているかを記録しません。 代わりに、どのUTXOがどの公開鍵ハッシュまたはスクリプトハッシュによってアンロックできるかを記録します。 ただし、公開鍵ハッシュまたはスクリプトハッシュから対応するアドレス(ウォレットインタフェースに表示される一連の文字列であるような意味不明なもの)を迅速に導出できます。
特定のアドレスに関連付けられたビットコインの量をブロックエクスプローラやウォレットインターフェースで表示できる理由は、これらのサービスがブロックチェーンデータを解析して解釈するためです。彼らはすべてのブロックをスキャンし、ロックスクリプトで宣言された公開鍵ハッシュまたはスクリプトハッシュに基づいて、対応する「アドレス」を計算します。これにより、そのアドレスに関連付けられたビットコインの量を表示できるようになります。
P2SHを理解することで、BitVMの重要なコンポーネントであるTaprootに近づくことができます。ただし、Taprootに飛び込む前に、WitnessおよびSegregated Witness(SegWit)の概念を把握することが重要です。ロック解除およびロックスクリプト、またUTXOロック解除プロセスを見直すと、取引のデジタル署名がロック解除スクリプトに含まれているという問題が浮かび上がります。この署名を生成する際、ロック解除スクリプト自体は署名を生成するデータの一部にはなりません(署名自体は使用されるパラメータに含まれないため)。
したがって、デジタル署名は、アンロックスクリプト以外の取引データの一部しかカバーすることができず、それにより取引データ全体を完全に保護することはできません。これにより、中間者がアンロックスクリプトをわずかに変更して署名の検証に影響を与えることなく、脆弱性が生じます。たとえば、Bitcoinノードやマイニングプールがアンロックスクリプトに追加データを挿入する可能性があります。この変更は検証や取引結果に影響を与えないものの、取引データをわずかに変更し、それにより計算される取引ハッシュ/取引IDも変更されます。この問題は取引の可変性として知られています。
これに問題があるのは、お互いに依存する複数の連続した取引を開始する予定の場合(たとえば、取引3は取引2の出力を参照し、取引2は取引1の出力を参照する)、後続の取引は前の取引のハッシュを参照する必要があります。 マイニングプールやビットコインノードなどの中間者は、アンロックスクリプトにわずかな修正を加えることで、取引ハッシュをブロックチェーンに記録される際に予期したものとは異なるものにすることができます。
この不一致は、相互依存トランザクションの事前に計画されたシーケンスを無効にする可能性があります。この問題は、DLCブリッジやBitVM2の文脈で特に関連しており、順次関連するトランザクションのバッチが構築されるため、このようなシナリオが非常に一般的です。
簡単に言えば、取引の可変性の問題は、取引ID/ハッシュの計算にアンロックスクリプトからのデータが含まれているため発生します。ビットコインノードなどの仲介者は、アンロックスクリプトをわずかに変更することができ、それによりユーザーの期待と一致しない取引IDが生成されます。この問題は、ビットコインの初期設計上の制限に起因しています。セグリゲーテッドウィットネス(SegWit)アップグレードは、取引IDをアンロックスクリプトから切り離すことでこの問題に対処します。SegWitにより、取引ハッシュの計算にはアンロックスクリプトのデータが含まれなくなります。SegWitの下でのUTXOロックスクリプトは、「OP_0」オペコードでマーカーとして始まり、対応するアンロックスクリプトはSigScriptからWitnessに名前が変更されます。
分離された証人(SegWit)ルールに準拠することにより、トランザクション展性の問題は効果的に解決され、ビットコインノードによってトランザクションデータが改ざんされるという懸念が排除されます。P2WSH(Pay to Witness Script Hash)の機能は、P2SH(Pay to Script Hash)と基本的に同じです。UTXOロックスクリプトでスクリプトハッシュをプリセットすることができ、ロック解除スクリプトを送信した人は、対応するスクリプトコンテンツをチェーンに提供して実行します。ただし、必要なスクリプトの内容が非常に大きく、多くのコードが含まれている場合、従来の方法ではスクリプト全体をビットコインブロックチェーンに送信できない場合があります(ブロックサイズの制限のため)。そのような場合、Taprootの出番です。Taprootは、オンチェーンのスクリプトコンテンツの圧縮を可能にし、より大きなスクリプトの処理を可能にします。BitVMはTaprootを活用して、より複雑なソリューションを構築します。次回の「BTCに近づく」連載では、Taprootやプリシグネチャーなど、BitVMに関する高度な技術について詳しく解説していきます。ご期待ください!