原作者：シノビ
オリジナルコンピレーション：ブロックユニコーン
提案の範囲はかなり広いにもかかわらず、Rusty Russell の「Great Script Recovery」がビットコイン開発の前進となる可能性がある理由は何でしょうか?
ユニコーンをブロックする 注: Rusty Russell はビットコイン コミュニティで積極的な開発者であり、コミュニティ内で非常に尊敬されています。彼は Linux カーネル開発で優れた仕事をしており、多くの Bitcoin Core 開発プロジェクトにも参加しています。
ビットコインはもともと、ユーザーが将来思いつく可能性のあるあらゆる潜在的なセキュリティのユースケースをカバーおよびサポートするように設計された完全なスクリプト言語を使用して設計されました。サトシ・ナカモトは失踪する前にこう言った。
「ビットコインの性質上、バージョン 0.1 がリリースされると、そのライフサイクル全体にわたってコア設計が設定されるということです。したがって、考えられるすべてのトランザクション タイプをサポートするように設計したいと考えています。問題は、特別なサポート コードです。データ フィールドが必要であるため、使用するかどうかに関係なく、多数の特殊なケースが発生します。これを解決するには、問題を一般化して、双方が特定の条件を使用してトランザクションをノード ネットワークに記述できるようにします。これらの条件に基づいて評価または検証されました。」 - サトシ・ナカモト、2010 年 6 月 17 日。
彼の全体の目的は、ユーザーが必要に応じて独自のトランザクション タイプを編成できるようにするのに十分な汎用性の高い言語を提供することです。つまり、ユーザーが独自の通貨をコーディングする方法を設計して実験する余地を与えます。
サトシは失踪する前に、これらのオペコードのうち 15 個を削除して完全に無効にし、スクリプト エンジン スタックに操作可能なデータ ブロックのサイズ (520 バイト) を制限するハード制限を追加しました。これは、彼が実際に失敗し、複雑なスクリプトを使用してネットワーク全体に DOS 攻撃 (大量のスパム要求を送信し、ネットワークを停止させる) を実行し、巨大で高価なトランザクションを作成できる方法を多数残したままになっているためです。ノードがクラッシュする原因となります。
これらのオペコードは、サトシ ナカモトがこれらの機能が危険である、または人々がこれらの機能を使用して何かを構築できるべきではないと考えたため削除されたのではなく、単に (少なくとも表面的には) リソースの制約なしで使用されたため、シナリオにリスクが生じたためです。これにより、最悪の場合の検証コストを制限なくネットワークに課すことができます。
それ以来、Bitcoin へのすべてのアップグレードは、最終的には残りの機能の機能最適化となり、サトシが残した他のそれほど深刻ではない欠陥を修正し、残りのスクリプトのサブセットの機能を拡張することになりました。
回復のための素晴らしいスクリプト
5月初旬にオースティンで開催されたBitcoin++カンファレンスで、ライトニングネットワークの中核開発者であるラスティ・ラッセルはカンファレンスの最初の講演で非常に過激な提案を行い、基本的にサトシ・ナカモトを再度有効にすることを提案した。そのアイデアは、2010年に消滅する前にほとんどのオペコードを無効にすることであった。
プライバシー、セキュリティ、スケーラビリティの向上を目的としたビットコインのメジャーアップグレードであるタップルートが 2021 年に有効化されて以来、数年間、開発状況はやや目的のないものになっていました。私たちは皆、ビットコインが世界のかなりの規模の自己主権人口に真にサービスを提供するには十分な拡張性がないことを知っています。おそらく、非常に大規模な管理者やサービスプロバイダー、サービスを超えて拡張できるように信頼や管理を最小限に抑える方法でさえもです。プロバイダーは、スケーラビリティを提供するために政府の長い権限から逃れることができません。
この記事では、ビットコインの技術的な理解を指摘しますが、これは議論する必要のある問題ではありません。議論の余地がある問題は、この欠陥にどのように対処するかということであり、非常に物議を醸しているトピックです。 Taproot が導入されて以来、特定のユースケースでのみ可能となる問題を解決することを目的とした、非常に狭い提案を全員が考え出してきました。
たとえば、ANYPREVOUT (APO) は、入力スクリプトと金額が同じである限り、署名を別のトランザクションで再利用できるようにする提案です。この提案は、特に Lightning ネットワークとそのマルチパーティ バージョンを最適化するように設計されています。 CHECKTEMPLATEVERIFY (CTV) は、事前定義されたトランザクションと完全に一致するトランザクションによってのみコインが使用されることを要求する提案であり、事前署名されたトランザクション チェーンを完全にトラストレスにすることでその機能を拡張するように設計されています。 OP_VAULT は、コールド ストレージ スキームの「タイムアウト期間」を設定するように特別に設計されており、ユーザーがキーの侵害を防ぐためにコールド ストレージからの抽出をよりコールドなマルチシグ設定に送信して「キャンセル」できるようになります。
他にもたくさんの提案がありますが、要点は理解できたと思います。過去数年間のすべての提案は、スケーラビリティをわずかに向上させるか、またはそれが望ましいと考えられた単一の小さな機能を改善するかのいずれかに関するものでした。これが議論が進まない根本です。他の提案は、彼らが望んでいたユースケースを満たしていなかったため、誰も満足しませんでした。
提案提案者以外の誰も、提案が合理的な次のステップとみなされるほど十分に包括的であるとは考えていません。
これが「脚本の大回復」の背後にある論理です。サトシが当初設計したように、スクリプトの完全なリカバリをプッシュして分析することで、現時点ではどの小さな機能拡張が十分であるかについて議論したり内輪もめしたりするのではなく、必要な機能空間全体を実際に探索してみることができます。
OPCODES (オペレーションコード)
OP_CAT: スタックから 2 つのデータを取得し、それらを加算して 1 つのデータを形成します。
OP_SUBSTR: 長さパラメータ (バイト単位) を受け入れ、スタックからデータの一部を取得し、その長さのバイトを削除してスタックに戻します。
OP_LEFT および OP_RIGHT: 長さパラメーターを受け入れ、スタックからデータの一部を取得し、その一方の側またはもう一方の側から指定された長さのバイトを削除します。
OP_INVERT、OP_AND、OP_OR、OP_XOR、OP_UPSHIFT、OP_DOWNSHIFT: データ要素を受け取り、それに対応するビット操作を実行します。
OP_ 2 MUL、OP_2D IV、OP_MUL、OP_DIV、および OP_MOD: 乗算、除算、およびモジュロ演算 (除算の剰余を返す) の数学演算子。
Rusty Russell は、回復用に上記にリストしたオペコードに加えて、異なるオペコードの組み合わせを簡素化するために設計された 3 つの追加オペコードを提案しました。
OP_CTV (または TXHASH/同等のオペコード): トランザクションの特定の部分をきめ細かく適用でき、それらの部分が事前定義されたコンテンツと正確に一致する必要があります。
CSFS: トランザクション全体だけでなく、署名の検証を許可します。これにより、使用されるスクリプトまたはデータの特定の部分は、実行前に署名される必要があります。
OP_TWEAKVERIFY: 集合公開鍵に対する単一の公開鍵の加算または減算など、公開鍵を含む Schnorr ベースの操作を検証します。これを使用すると、一方の当事者が共有未使用トランザクション出力 (UTXO) を一方的に離脱するときに、他のすべての当事者の資金が、協力して支出するために離脱当事者の署名を必要としない集約パブリックに送信されるようにすることができます。
なぜこれを行うのか
レイヤ 2 ネットワークは本質的にビットコインのベース レイヤの拡張であり、ベース レイヤの機能によって機能的に制限されます。 Lightning Network を実際に実装するには、CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY (CSV)、および Segregated Witness の 3 つの個別のソフト フォークが必要でした。
より柔軟なベース レイヤがなければ、より柔軟なレイヤ 2 ネットワークを構築することはできません。唯一の近道は、サードパーティを信頼することです。これは非常にシンプルで明白です。私たち全員が、大規模なビットコインとのやり取りのあらゆる側面からサードパーティからの信頼を可能な限り排除することを望んでいます。
現時点では 3 つ以上を 1 つの未使用トランザクション出力 (UTXO) に安全にマージすることは不可能ですが、それをベース レイヤでトラストレスに実行できるようにする必要があります。ビットコイン スクリプトは現時点では十分な柔軟性がありません。最も基本的なレベルでは、コントラクトが必要であり、あるユーザーが他のユーザーの資金を危険にさらすことなく安全に自分の UTXO を終了できるように、トランザクションの実行に関する詳細を実際に強制できるスクリプトが必要です。
大まかに言うと、必要な機能は次のとおりです。
イントロスペクション: 「この金額が特定の出力のこの公開キーに送られる」など、支出トランザクション自体に関するスタック上の特定の詳細を実際に検査できる必要があります。これにより、私自身の特定の Taproot ブランチを使用して自分の資金を引き出すことができる一方で、他の人の資金を引き出すことはできません。実行されたスクリプトは、他の所有者の資金が他のユーザーの公開鍵で構成されるアドレスに送り返されることを保証し、他の参加者による資金の損失を防ぎます。
前方データの伝送: 多数の人が参加する単一の UTXO の概念をさらに発展させ、誰もが自由に出入りできるとします。この場合、通常はマークル ツリーとそのルートを使用して、誰がどれだけのお金を持っているかを追跡する方法が必要です。これは、誰かが退職したときに、他の全員の資金の変更UTXOの一部として、誰が何を受け取る権利があるかを必ず「記録」する必要があることを意味します。これは基本的に、内省の具体的な使用法です。
公開キーの変更: 集合公開キーへの変更がスタック上で検証できることを確認する必要があります。 Unspent Transaction Output (UTXO) 共有スキームでは、すべての参加者を含む集約された公開キーを通じて協力と効率的な資金の流れを促進することが私たちの目標です。誰かが一方的に共有 UTXO から離れる場合、集合公開鍵からその個人の公開鍵を削除する必要があります。考えられるすべての組み合わせが事前に計算されていない場合、唯一のオプションは、集合公開キーから 1 つの公開キーを差し引いた結果、残りの個別の公開キーから構成される有効な公開キーが得られることを検証することです。
安全を確保する方法: VAROPS 上で述べたように、これらのオペコードをすべて無効にする理由は、ネットワークを構成するノードのクラッシュを引き起こす可能性のある DOS 攻撃 (大量のジャンク リクエストを送信してネットワークをクラッシュさせる) に対処するためです。この問題を解決する 1 つの方法は、これらのオペコードのいずれかが使用できるリソースの量を制限することです。
ビットコイン スクリプトの最も高価な部分である署名検証に関しては、これに対するソリューションがすでにあり、それは署名操作 (sigops) 予算編成と呼ばれています。署名チェック オペコードを使用するたびに、特定の「予算」が消費されます。これは、ブロックごとに許可される署名操作の数であり、ブロックを検証するためにユーザーがトランザクションで発生する可能性のあるコストのハード制限を設定します。
Taproot はこの動作方法を変更し、単一のグローバル ブロック制限を使用する代わりに、各トランザクションにはトランザクションのサイズに比例した独自の sigops (署名操作) 制限があります。これは本質的に同じグローバル制限に相当しますが、トランザクションごとに利用可能な sigops の数を理解しやすくなります。
各トランザクションの sigops (署名操作) 制限の処理方法に関する Taproot の変更により、一般化アプローチの可能性が開かれます。これは、varops 制限に関して Rusty Russell によって提案されたものでもあります。このアイデアは、各オペコードが引き起こす可能性のある最悪のシナリオ、つまり検証時に発生する最も高価な計算コストを考慮して、再アクティブ化された各オペコードにコストを割り当てることです。このようにして、各オペコードには独自の「sigops」制限があり、検証プロセス中に消費できるリソースの量が制限されます。これは、これらのオペコードを使用するトランザクションのサイズにも基づくため、ブロックごとの暗黙的なグローバル制限を超えたまま推論を容易にすることができます。
これにより、これらのスパム トランザクションによる DOS 攻撃 (大量のスパム リクエストを送信してネットワークをクラッシュさせる) が解決されます。サトシが最初にこれらのオペコードをすべて無効にしたのはそのためです。
前進の勢い
「変わりすぎでは？」と思われる方も多いと思いますが、その考えは理解できますが、提案として理解しておくべき重要な点は、すべてを行う必要はないということです。この提案の価値は、必ずしもこれらすべての機能を完全に復元することにあるわけではありませんが、基本コンポーネントの大規模なスイートを包括的に検討し、機能の観点から本当に必要なものは何かを自問するという点にあります。
それは、特定の機能のみを備えた小さく狭い変更について議論していた過去 3 年間の口論と議論からの完全な転換となるでしょう。みんなで集まって今後の方向性を検討する広場のようなものです。おそらく最終的にはこれらの機能をすべて復元することになるでしょう。あるいは、これらの機能はオンにする必要があると全員が同意しているというコンセンサスがあるため、最終的にはいくつかの機能だけをアクティブにすることになるかもしれません。
最終的な結果が何であれ、これは私たちの将来の方向性に関する会話全体にプラスの影響を与える変化となる可能性があります。次にどの道を進むべきか、手探りで検討するのではなく、実際に計画を立てて状況の全体像を把握することができます。
これは決して私たちが進まなければならない道ではありませんが、私たちがどの道を進みたいかを決める最大のチャンスだと思います。実践的かつ生産的な方法で再び協力し始める時期が来ています。
