Taprootがビットコインにやってくる：それがどのように機能するか、その歴史と意味

Taproot と Schnorr の署名は、ビットコインのブロック 709,632 で公開されます。 これは、将来にわたって継続的に構築される大きな基礎的な成果となるでしょう。 Segregated Witness がネットワーク上で稼働し始めてから XNUMX 年が経ち、最後のメジャー プロトコル アップグレードが行われました。 それは半減期と同じくらい長いです！

それについて考えてみましょう。 SegWit の稼働から Taproot の稼働まで XNUMX 年。 ゆっくりとした、几帳面な忍耐力。 しかし、Taproot/Schnorr の歴史はそれよりもはるかに遡ります。

タップルートの歴史

しばらくここに来ている人はこれを皮肉だと思うかもしれませんが、私が知っているシュノア署名についての最初の言及は、実際には元ビットコインコア開発者からエンタープライズブロックチェーンビルダーに転身したマイク・ハーンによるものでした。 2012年に彼は、 育て ノード検証の計算コストを削減するための、署名のバッチ検証に関連した新しい暗号曲線のアイデア。 結局のところ、彼が提案していた計画はシュノアの署名に依存していました。

アダム・バックはナイーブについて話していた スキーム 2014 年には、Schnorr 署名を利用して、シングルシグ アドレスに似たマルチシグ アドレスを実行しました。 ギャビン・アンドレセンも参加 ECDSA の代わりに Schnorr 魔法の杖を振ることができたらビットコインに加えたい変更のウィッシュリストに載っている。

ビットコインの初期に近い頃から、ビットコイン コアに積極的に関わっているほとんどの開発者は Schnorr 署名を望んでおり、ECDSA 署名に対する Schnorr 署名の優位性については常にかなり堅固なコンセンサスが存在していました。 実際、ECDSA は、Schnorr 署名スキームが特許を取得しており、特許に邪魔されないオープンソースの暗号署名スキームに対する大きなニーズがあったために特別に作成されたと主張することもできます。

Schnorr は ECDSA よりもはるかに効率的で、簡単に操作できます (署名に追加したり削除したりすることができ、正しく実行すれば、有効な署名を必要なときにユーザーに残すことができます)。 ECDSA の使用は、長年にわたり、ほとんどの暗号アプリケーションにおいて要望ではなく必然でした。

今回の Taproot アップグレードの Taproot の半分である Merkelized Abstract Syntax Trees (MAST) にも、同様の長年の歴史があります。 出典を見つけることができませんでしたが、2013 年か 2014 年頃にピーター トッドのような人たちが Bitcointalk.org でこのフレーズを投げかけていたのを見たときのことをはっきりと覚えています。

オリジナル MAST 用 BIP この提案は 2016 年に Johnson Lau によって提案されました。この提案は、Mark Friedenbach、BTCDrak、Kalle Alm によって 2017 つの別個の BIP に分割された XNUMX 年頃にいくつかの活動も見られました (116 & 117）そしてラウのオリジナルの提案を拡張しました。

MAST は、グレッグ・マックスウェルが最初のタップルートのアイデアを思いつくまで、翌年は宙ぶらりんの状態でした。 公表 bitcoin-dev メーリング リストに送信してください。 彼の重要な洞察は、彼が考えることができる複数の参加者間のどのような契約ケースにも、より高度なスクリプトやトランザクションで結果を強制するのではなく、適切な結果に署名するだけで全員が契約を解決できる「最適な結果」が存在するということでした。 これは、Taproot が基づいている基本的な主張です。つまり、他の支出条件のマークル ツリーが存在するかどうかすら明らかにせずに支出できる通常のトップレベル キーに MAST ツリーを微調整することです。

この歴史レッスンの最後の部分は、ピーテル・ヴィウレの発表から始まります。 BIP 草案 Schnorr と Taproot は、6 年 2019 月 2020 日にメーリング リストに共同で参加しました。XNUMX 年 XNUMX 月までに、これは正式に最終決定されました。 BIP 340、341、および 342。 この時点からは、実装レベルで多くの細かい詳細を調整し、ある程度のレビュー期間を経て、その後、長い期間にわたって作業が行われました。 活性化メカニズムをめぐる戦い。 それが、アクティベーションを目前に控えた現在につながります。

Schnorr 署名の重要性

それでは、Schnorr 署名の何が重要なのでしょうか? まず、取引の規模を小さくします。 ECDSA 署名のサイズは、通常、トランザクション内の 72 つの署名に対して約 64 バイトです。 Schnorr 署名は、署名ごとに最大 12 バイトでクロックインします。 これは、すべての Schnorr 署名の ECDSA と比較して、サイズが約 XNUMX% 節約されることになります。 これは、ECDSA ユーザーよりも少ない料金で Schnorr を使用する人にとって直接的なメリットですが、他の人の Schnorr を処理して検証するためにブロックチェーンに保存するデータがわずかに少なくて済むため、Schnorr を使用していない人にとっても直接的なメリットになります。署名。

保存するデータが少ないことは常に良いことですが、さらに良いのは、保存する必要があるデータの検証の効率が向上することです。 Schnorr の優れた特性の XNUMX つである、その背後にある数学の直線性により、ビットコイン データに必要な優れた特性であるバッチ検証も可能になります。 ノードがネットワークからブロックを受信すると、ノードは個々のトランザクションを解析し、各署名を XNUMX つずつ検証します。

これが、ブロックの検証で大量の CPU パワーが消費される理由の大きな部分を占めています。 Schnorr 署名はすべてまとめてバッチ処理し、一度に数学的に検証することができます。これは、個別の署名をまとめて実行するのではなく、まとめて XNUMX つの数学演算を実行するようなものです。 したがって、Schnorr 署名が多いほど、計算量の節約が大きくなります。 これはネットワークにとって大規模なスケーリングの勝利です。

Schnorr がもたらすもう XNUMX つの大幅な改善は、マルチシグネチャ スクリプトです。 すべてのマルチシグ アドレスは、支出時にマルチシグ スクリプトに含まれる個々の公開キーのすべてを明示的に明らかにする必要があり、署名は支出プロセスに関与するすべてのキーに提供される必要があります。 Schnorr の数学的特性により、マルチシグネチャ標準である MuSig への扉が開きます。 キーを追加するだけで、新しい署名プロトコルを使用して全員の秘密キー共有に署名できる XNUMX つの公開キーを作成できます。 ブロックストリームのジョナス・ニック ベンチマークされた MuSig2 の所要時間は XNUMX 分です 100万 マルチシグ アドレスの参加者が署名する必要があります。 マルチシグネチャ スクリプトのスケーリングの向上を軽視することはできません。

マルチシグネチャ スクリプトのこの大きな進歩は、ビットコイン上に構築された多数のアプリケーションのプライバシー プロファイルとコストにも大きな影響を及ぼします。 MuSig ベースの Lightning チャネルは、チェーン上の Schnorr/Taproot UTXO の匿名セット全体に溶け込むことができるようになりました。これは、もう XNUMX-of-XNUMX マルチシグ出力であるという事実を誰も区別できないためです。

これらは溶け込み、単一の署名スクリプトのように見えます。 一般に、マルチシグ UTXO についても同じことが当てはまります。 これは、単一の署名スクリプトよりも堅牢なセキュリティと回復モデルでコールド ストレージをより適切に保護するためにマルチ署名スクリプトを使用しているユーザーにとって、多くの影響を及ぼします。

第一に、ブロックチェーンを見ていてもマルチシグ設定を使用していることは明らかではないため、Lightning の場合と同様に、他のものと調和してしまいます。 ただし、重要な利点は経済面にあります。現時点でマルチ署名を使用するには、最終的に UTXO を消費する際に関係するすべてのキーに個別の署名を提供する必要があります。 Schnorr/MuSig を使用すると、単一の結合された公開鍵の単一の署名に圧縮されます。つまり、ブロックチェーンにプッシュされるデータが少なくなるため、MuSig を使用したマルチシグ UTXO の費用が大幅に安くなります。

Schnorr シグネチャが行う最後の優れた点は、アダプタ シグネチャの実装を大幅に簡素化することです。 有効な署名に加算または減算された値によって「暗号化」されたアダプタの署名を考えてみましょう。 その数学的演算を逆にするか、操作に使用された「キー」を使用して「復号化」するまでは有効ではありません。 これは ECDSA で可能ですが、Schnorr に比べて計算が非線形であるため比較的複雑で、実装する際にはセキュリティ上の懸念事項が多くあります。

ただし、Schnorr の線形特性により、アダプター シグネチャは、単一の値 (たとえば、9,300,030) を取得し、そこから値 (たとえば、30) を引くだけで簡単になります。 アダプターの署名を保持している側が減算された値を学習したら、単純にそれを加算し直すことができます。 出来上がり、彼らは再び有効な署名を持っています。

主根の意味

上で少し説明したように、Taproot は実際には本質的に単なる MAST ですが、P2SH のように動作する代わりに (スクリプトをハッシュするか、MAST の場合はスクリプト ツリーの最上部のマークル ルート)、 Merkle ツリーのルートにある Schnorr 公開キー。

微調整は Schnorr の線形特性により機能します。マークル ルートを使用して公開鍵を「微調整」する (そのマークル ルートを公開鍵に追加する) と、元の秘密鍵にマークル ルートを追加するだけで、新しく調整された公開キー。 つまり、公開キーと秘密キーの両方に同じものを追加しても、それらは有効なキー ペアのままです。 これにより、MAST ツリーのブランチが使用されない限り、MAST ツリーの存在が隠蔽されますが、基本的には依然として単なる MAST ツリーであり、より効率的かつプライベートな方法でコミットされたものにすぎません。

マークル ツリー内のさまざまな支出スクリプトにコミットし、使用されたスクリプトのみを明らかにする機能は、ビットコイン上に構築可能なスマート コントラクトの複雑さの点で、スケーラビリティに大きなメリットをもたらします。

ブロック サイズによってブロックごとのトランザクション数が制限されるのと同様に、トランザクション サイズには 100 キロバイトの制限があります。 唯一の違いは、これがコンセンサス ルールではなくポリシー ルールであることです。 つまり、マイナーは 100 キロバイトを超えるトランザクションをマイニングできますが、デフォルトでは、ネットワーク上のノードはそもそもそれより大きなトランザクションをマイナーに中継しません。

これにより、ビットコイン UTXO をロックするために使用されるスクリプトのサイズが本質的に制限されます。 UTXO がスクリプトのハッシュにロックされ、使用するまで公開されない P2SH を使用しても、最終的には使用時に完全なスクリプトを公開する必要があります。 Taproot は、使用時にスクリプト全体を公開する必要がないため、スクリプトのこのスケーラビリティ制限を高めます。 UTXO を使用できるすべての方法の合計サイズがトランザクション サイズ制限に制限されるのではなく、Taproot UTXO を使用できる XNUMX つの方法がこの制限を遵守していることを確認するだけで済みます。

Taproot にはプライバシーに関するメリットも数多くあります。 MAST ツリーの大きな利点の XNUMX つは、他の当事者がコインを使用できるあらゆる種類の条件付き状況を作成できることです。

相続制度のようなものを想像してみてください。XNUMX 年ほど経つと子供たちがあなたのコインを使うことができるようになります。また、あなたが署名を拒否した場合、妻と弁護士がコインを回収する可能性があるということです。 これらの支出条件については、実際に使用されない限り、何も公開されません。 この XNUMX つのプロセスにより、UTXO への関与について、構築したさまざまな支出分岐に関与する他の関係者にもっともらしい否認が提供されるだけでなく、彼らがある程度の制御権を持っていることを知りながら先制的にターゲットにする泥棒や攻撃者から保護されます。ターゲットのUTXO。

技術レベルでも、Taproot は比較的よく設計されています。 これを読んでいる人で、隔離された証人に深いレベルで精通している人は誰でも、証人のバージョンに精通しているはずです。

Segregated Witness が実装されると、署名データが移動されるトランザクションの新しい「監視」セクションが作成されました。 ウィットネス データにはバージョン フラグが付いていたため、新しい機能のためにベース レイヤ上の未定義の OP_CODE を使い切ることなく、新しい機能にアップグレードできました。

これは実際に Taproot/Schnorr が実装された方法です。 分離された監視トランザクションは、監視バージョン XNUMX を使用します。 Taproot/Schnorr が間もなく稼働すると、新しい Witness バージョン XNUMX を使用して、古い Segregated Witness トランザクションと区別する予定です。 SegWit が監視バージョンを導入したのと同じ方法で、Taproot は、Taproot を使用する UTXO の MAST ツリーで使用されるタップスクリプトに「tapleaf バージョン」を導入します。 これにより、ベース レイヤで新しい OP_CODE を使用せずに、MAST に埋め込まれたスクリプトをアップグレードできるだけでなく、監視バージョンもアップグレードする必要がなくなります。 したがって、Taproot は、プロトコルに対する他の無関係なアップグレードを制限することなく、将来のアップグレードを可能な限り効率的に行うように設計されました。

Taproot はさまざまなユースケースをもたらします。 まず、ペナルティキーやそれらの使用を許可するタイムロックなど、Lightning チャネル内のすべての非協力条項は、Taproot を使用して MAST の下に埋め込むことができます。 使用する必要がない限り、その存在に誰も気付かないため、どの UTXO が実際に Lightning チャネルであるかどうかがさらにわかりにくくなります。

継承スキームも別の使用例です。 XNUMX か月間お金を動かさなかった後、家族全員が集まって UTXO を好きなように使えるように構成されたタップルート ツリーを想像してください。 そして、XNUMX か月後、XNUMX 人を除いた全員がそれを使用できるようになります (つまり、妻、XNUMX 人の子供、両親をキーホルダーとして持っていたと想像してください。その後、追加の XNUMX か月後に、妻、XNUMX 人の子供、両親が署名できると想像してください) 、または、妻なしで XNUMX 人の子供と両親が署名することもできます。など）。

そして半年後はXNUMX人を引いた全員が過ごせるようになります。 最終的には、（不正行為が起こらないようにするため）弁護士の助けを得て、UTXO を使えるのは XNUMX 人だけになる可能性があります。

あるいは、マルチシグを使用して冷蔵倉庫のセキュリティを確保しているが、長期的に安全で予測可能な場所が XNUMX か所しかない場合はどうなるでしょうか? 最終的には、数年後に、他の鍵が紛失または破壊された場合に備えて、その安全な場所にある鍵がそれらのコインだけを使用できるようにする MAST を作成できますが、その場合でもコインが即座に盗難の危険にさらされることはありません。 XNUMXつの鍵が侵害されました。

これは、ビットコインに対する驚くべき包括的なアップグレードであり、実際の実装の詳細が検討され実装されたのはここ数年だけではなく、おそらくビットコイン自体の誕生のほぼ時から取り組んできたものです。

これは、ビットコイン プロトコルのスケーラビリティと実用性にとって非常に多くの点で本当に勝利ですが、その一部がどれほど微妙で「セクシーではない」ため、伝えるのは困難です。 しかし、それは勝利を損なうものではありません。 タップルートが登場するので、みんなでシートベルトを締めて、すぐに使用する新しいおもちゃで遊ぶ準備をしましょう。

忍によるゲスト投稿です。 表明された意見は完全に独自のものであり、必ずしもBTCIncまたは Bitcoin Magazine.

出典: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer