提案の範囲はかなり広いですが、なぜラスティ・ラッセルの「グレート・スクリプト・リカバリー」がビットコイン開発の前進の道と見なされているのか、その理由は何でしょうか？

ブロックユニコーンノート：Rusty Russellはビットコインコミュニティで活発な開発者であり、その中で非常に尊敬されています。彼はLinuxカーネル開発に注目すべき貢献をし、さまざまなBitcoin Core開発プロジェクトに関与してきました。

Bitcoinが最初に設計されたとき、将来ユーザーが提案するかもしれないあらゆるセキュリティユースケースをカバーしサポートすることを意図した完全なスクリプト言語が含まれていました。Satoshi Nakamotoが消える前に述べたように:

"Bitcoinの性質は、バージョン0.1がリリースされると、そのコア設計が将来のいかなる時点でも確立されるというものです。そのため、私は可能なすべての取引タイプをサポートするように設計しましたが、後のバージョンでは、任意のスクリプトを実行する機能を削除しました。問題は、すべての機能には特別なサポートコードとデータフィールドが必要であり、使用されているかどうかに関係なく、多くの特別なケースにつながったことです。解決策は、トランザクションがその条件を特有の方法で記述できるようにするスクリプトであり、ネットワークノードがこれらの条件を評価および検証できるようにしました。" - Satoshi Nakamoto、2010年6月17日

その目的は、ユーザーが自分の希望に応じてトランザクションタイプを整理するために十分に汎用的な言語を提供することでした。言い換えると、ユーザーには、自分のお金をどのように書くかを設計して試行するスペースが与えられます。

彼の失踪前に、Satoshi Nakamotoは15個のオペコードを削除し、それらを完全に無効にし、スクリプトエンジンスタック（520バイト）で動作できるデータブロックのサイズに厳しい制限を追加しました。これは、彼が実質的に失敗したためであり、非常に複雑なスクリプトが使用されてDOS攻撃が可能になる多くの方法が残され、ネットワーク全体にDOS攻撃を行うことができるようになりました（多くのジャンクリクエストを送信し、ネットワークを麻痺させる）、大規模でコストのかかるトランザクションを作成し、ノードをクラッシュさせる可能性がありました。

これらのオペコードは、サトシ・ナカモトがこれらの機能を危険と見なしたために削除されたわけではなく、人々がそれらを利用して何を構築するべきではないと考えたためでもなく、単純に（少なくとも表面上は）リソース制限なしにネットワーク全体にリスクをもたらし、それによってネットワークに最悪の検証コストを課す可能性があるため削除されました。

それ以降、すべてのビットコインのアップグレードは、最終的に残りの機能の最適化であり、別の軽微な欠陥を修正し、我々に残されたスクリプトのサブセットの機能を拡張してきました。

素晴らしいスクリプトの回復

ビットコイン++会議では、初めてのトークで、コアのライトニングネットワーク開発者であるラスティ・ラッセルが、2010年にサトシ・ナカモトが消失する前に無効にされたほとんどのオペコードを再度有効にするという非常に過激な提案を行いました。

2021年にTaprootが活性化されて以来（Taprootはビットコインを改善してプライバシー、セキュリティ、スケーラビリティを向上させることを目指した重要なアップグレードです）、開発領域はやや目的を持たずに進んできました。ビットコインが真に主権的なサービスを世界の重要な人口に提供するには十分なスケーラビリティがないこと、または最小限の信頼性や保管方法で非常に大規模な保管機関やサービスプロバイダーを超えることができないこと、そして政府の監視の制約から真に逃れることができないことは十分に認識されています。

この記事は、議論の余地のないビットコインの技術レベルでの理解を強調しています。議論の余地のある問題は、非常に論争の的となっているこの欠陥をどのように解決するかです。Taprootの提案以来、特定のユースケースでのみ達成可能な問題を解決することを目指した非常に狭い提案が続々と出されています。

例えば、ANYPREVOUT（APO）は、入力スクリプトと金額が同じであれば、署名を異なる取引で再利用できるようにする提案です。この提案は、特にライトニングネットワークとそのマルチパーティバージョンを最適化するように設計されています。CHECKTEMPLATEVERIFY（CTV）は、コインが事前に定義された取引と完全に一致する取引のみによってのみ消費されるようにする提案です。この提案は、事前署名された取引チェーンの機能を拡張し、それらを完全に信頼できるものにすることを目的としています。OP_VAULTは、ユーザーがコールドストレージからの引き出しを「キャンセル」できるようにするために、「タイムアウト」を設定するように特に設計されています。これにより、ユーザーはそれらをより冷たいマルチシグネチャセットアップに送信することで、キーが漏洩するのを防ぐことができます。

他にも多くの提案がありますが、私はあなたが主要なポイントを理解していると思います。過去数年間、各提案はわずかな拡張性の向上または単一の小さな機能の改善を目指しており、これが望ましいとされていました。これが議論が進展していない理由です。他の提案に誰も満足していないのは、彼らが見たいユースケースに適合していないからです。

提案者以外には、誰も提案が十分に包括的であるとは考えていないため、合理的な次の段階として考慮されるとは誰も考えていない。

これが「Great Script Recovery」のロジックです。サトシ・ナカモトが元々設計したように、スクリプトの包括的な復元を提唱し、分析することで、現在十分なものかどうかを議論し、論争するのではなく、必要な全機能空間を探索する試みができます。

OPCODES (Operation Codes)

• OP_CAT: スタックから2つのデータを取得し、それらを1つのデータに追加します。
• OP_SUBSTR：バイト単位で長さパラメータを受け取り、スタックからデータの一部を取得し、その長さのバイトを削除してスタックに戻します。
• OP_LEFTおよびOP_RIGHT：長さパラメータを受け入れ、スタックからデータの一部を取り出し、指定された長さのバイトをその片側または他側から削除します。
• OP_INVERT、OP_AND、OP_OR、OP_XOR、OP_UPSHIFTおよびOP_DOWNSHIFT: データ要素を受け入れ、それに対応するビット演算を実行します。
• OP_2MUL、OP_2DIV、OP_MUL、OP_DIV、およびOP_MOD：乗算、除算、および剰余演算のための数学演算子（除算の余りを返す）。

上記にリストされているオプコードに加えて、Rusty Russellは、異なるオプコードの組み合わせを簡素化するために3つの追加のオプコードを提案しました。

OP_CTV（またはTXHASH/同等のオペコード）：取引の特定の部分に対する細かい制限を許可し、これらの部分が事前に定義された内容と完全に一致することを要求します。

CSFS：トランザクション全体だけでなく、スクリプトまたは使用されるデータの一部が実行される前に署名する必要があることを確認できるようにします。

OP_TWEAKVERIFY：Schnorrベースの操作検証であり、個々の公開鍵を集約された公開鍵から加算または減算するなど、公開鍵を関与させる。これにより、共有された未使用取引アウトプット（UTXO）から片方が一方的に支出する際に、他のすべての当事者からの資金が共同支出を可能にする集約された公開鍵に送金され、共有UTXOを離れる当事者の署名を必要としないことを保証できます。

なぜやっているのですか？

Layer2ネットワークは基本レイヤーのビットコインの本質的な拡張であり、基本レイヤーの機能に制約されています。ライトニングネットワークを実装する前に、CHECKLOCKTIMEVERIFY（CLTV）、CHECKSEQUENCEVERIFY（CSV）、およびSegregated Witness（SegWit）の3つの別々のソフトフォークが必要でした。

より柔軟なベースレイヤーがないと、より柔軟なLayer2ネットワークを構築することは不可能です。唯一のショートカットは第三者を信頼することです。これは非常に簡単ですが、私たちはビットコインのスケーラビリティとのやり取りのあらゆる側面から可能な限り第三者への信頼を排除したいと願っています。

現在不可能なことを安全に行うことができるようにする必要があります。 例: 2人以上を1つの未使用トランザクション出力（UTXO）にまとめ、ベースレイヤーで信頼なしに実行できるようにすること。現在のビットコインスクリプトの柔軟性は不十分です。 最も基本的なレベルで、契約が必要であり、ユーザーが安全に自分のUTXOを退出させることが他のユーザーの資金を危険にさらさないようにするために、トランザクションの実行に関する詳細を実際に強制するスクリプトが必要です。

より高い視点から、これが必要な機能です:

内省: 実際にスタック上で支出トランザクションの特定の詳細を検査できる必要があります。 たとえば、「この部分の資金は特定のアウトプットの公開鍵に流れます」といった内容です。これにより、自分の特定のTaprootブランチを使用して資金を独立して引き出すことができるようになります。同時に、他の誰の資金も取ることはできないことが保証されます。実行されたスクリプトは、他の所有者の資金が他のユーザーの公開鍵で構成されたアドレスに戻されることを確実にし、他の参加者による資金の損失を防ぎます。

データの転送：1つの大量の人々を持つ単一のUTXOの概念をさらに発展させると仮定します。誰でも自由に入退場できる状況では、誰がいくらのお金を持っているかを追跡する方法が必要です。通常、Merkleツリーとそのルートを使用します。これは、誰かが退場するとき、他の人々の資金の変更UTXOの一部として何を受け取る権利があるかを「記録」する必要があることを意味します。これは基本的に内省の特定の使用法です。

公開キーの変更: 集約された公開キーへの変更がスタック上で検証できることを確認する必要があります。共有未使用取引アウトプット（UTXO）スキームでは、全参加者を含む集約された公開キーを介して資金の協力と効率的な流れを促進することを目指しています。誰かが一方的に共有UTXOから退出すると、集約された公開キーから個々の公開キーを削除する必要があります。すべての組み合わせが事前に計算されていない場合、残りの個々の公開キーで構成される有効な公開キーを生成するために、公開キーから公開キーを引くかどうかを検証する唯一の選択肢です。

セキュリティの確保: 上記で述べたように、これらのすべてのオペコードを無効にする理由は、DOS攻撃(大量のジャンクリクエストを送信することによってネットワークをクラッシュさせる攻撃)に対処するためであり、これによりネットワークを形成するノードのクラッシュが発生する可能性があります。この問題に対処する1つの方法は、これらのオペコードのいずれも使用できるリソース量を制限することです。

署名検証に関して、Bitcoin scriptの中で最もコストのかかる部分は、Signature Operation（sigops）予算と呼ばれる解決策が既に存在しています。署名確認のオペコードの使用ごとに一定の"予算"が消費され、つまり、ブロックごとに許可される署名操作の数が設定され、ユーザーに対してトランザクションを検証するために必要なコストに対する厳しい制限が設定されます。Taprootは、これを単一のグローバルブロック制限を使用せずに、各トランザクションごとに独自のsigops（署名操作）制限を持つことで変更し、トランザクションのサイズに比例しています。これは基本的に同じグローバル制限に等しくなりますが、各トランザクションが利用可能なsigopsの数を理解しやすくします。

Taprootに関するsigops（署名操作）リミットの変更は、一つのトランザクションごとに一般化されたアプローチの可能性を提供し、それはvaropsの制限に関するRusty Russellの提案でもあります。アイデアは、再アクティブ化された各opcodeごとにコストを割り当てて、各opcodeが検証中に作成できる最も高価な計算コストの最悪のシナリオを考慮に入れることです。したがって、各opcodeには独自の「sigops」リミットがあり、検証中に消費できるリソースの量が制限されます。これは、これらのopcodesを使用する取引のサイズにも基づいており、暗黙のうちに各ブロックの暗黙のグローバルリミットに蓄積されるまでの推論が便利になります。これにより、ネットワークのクラッシュを引き起こすDOS攻撃（大量のジャンクリクエストを送信することによる）が解決されるでしょう。これは、その理由でSatoshi Nakamotoが最初にこれらのopcodesを無効にした理由でもあります。

前進の原動力

多くの方が「それは大きな変化だ」と思うかもしれません。この視点は理解していますが、提案について理解する重要な側面は、すべてを一度に行う必要はないということです。この提案の価値は、これらすべての機能を完全に復元することにあるとは限らず、むしろ、基本的な構成要素の広範なスイートを徹底的に検討し、本当に望む機能性について自問自答することにあると考えています。

これは、過去3年間の議論や論争からの完全な転換を意味します。そこでは、われわれは単なる細かい、狭い変更について議論していた。特定の機能にしか影響を与えない変更でした。それはまるで、誰もが集まり、共に将来の方向を熟考することができる場所のようです。おそらく最終的には、これらの機能をすべて復元するかもしれませんが、あるいは、一部の機能のみを有効にするかもしれません。なぜなら、コンセンサスは、我々全員が有効にすべきと考えている機能に合意することについてのものです。

最終的な結果にかかわらず、これは私たちの将来の方向に関する対話全体に肯定的に影響を与える可能性がある変化であるかもしれません。次のステップを議論する際に、曖昧な道に先へ手探りで進むのではなく、状況を実際に整理し完全に理解することができます。

これは私たちが取るべき唯一の方法ではありませんが、私はこれが私たちがどの道を選ぶかを決める最良の機会を提供していると信じています。再び実践的かつ効果的な方法で一緒に働き始める時が来ています。

ステートメント:

1. この記事はもともと「伟大的脚本恢复：比特币の前進の道」のタイトルで、[から転載されましたブロックユニコーン]. すべての著作権は元の著者[SHINOBI]に帰属します。転載に異議がある場合は、お問い合わせください。ゲート レアンチーム、チームはできるだけ早く対応します。

2. 免責事項：この記事で表現されている意見は、著者個人の意見を表しており、投資アドバイスを構成するものではありません。

3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または剽窃は禁止されています。