ビットコインは当初、完全に肉付けされたスクリプト言語で設計され、ユーザーが将来思いつく可能性のある安全なユースケースを網羅してサポートすることを目的としています。サトシ自身が姿を消す前に言ったように:

「ビットコインの性質上、バージョン0.1がリリースされると、コアデザインは残りの生涯にわたって固定されました。そのため、考えられるすべてのトランザクションタイプをサポートするように設計したかったのです。問題は、使用されているかどうかにかかわらず、それぞれが特別なサポートコードとデータフィールドを必要とし、一度に1つの特別なケースしかカバーしていないことでした。それは特別なケースの爆発だったでしょう。解決策は、取引当事者がノードネットワークが評価する述語としてトランザクションを記述できるように問題を一般化するスクリプトでした。」 - サトシ、2010年6月17日。

全体的な意図は、ユーザーが適切だと思う独自のタイプのトランザクションを作成できるように、十分に一般的な言語を提供することでした。 つまり、ユーザーが自分のお金をプログラムする方法を設計し、実験する余地を与えます。

彼が姿を消す前に、サトシはこれらのオペコードのうち15個をリッピングし、それらを完全に無効にし、スクリプトエンジンスタックで操作できるデータの大きさ(520バイト)にハード制限を追加しました。これは、彼が率直に言って失敗し、複雑なスクリプトを使用してネットワーク全体をサービス拒否攻撃し、ノードをクラッシュさせるトランザクションを検証するために莫大でコストのかかる多くの方法を開いたままにしたためです。

これらのオペコードが削除されたのは、サトシが機能が危険であると考えたため、または人々がそれらを使用してできるものを構築できないはずだと考えたためではなく、ネットワークに課す可能性のある最悪のケースの検証コストを制限するために、リソースの制約なしに使用されるネットワーク全体へのリスクのためだけです(少なくとも明らかに)。

それ以来、ビットコインへのすべてのアップグレードは、最終的に残された機能を合理化し、サトシが私たちに残した他のそれほど深刻ではない欠陥を修正し、私たちが残したスクリプトのサブセットの機能を拡張しました。

THE GREAT SCRIPT RESTORATION

初旬にオースティンで開催されたビットコイン++で、Core Lightningの開発者であるRusty Russell氏は、カンファレンスの最初のプレゼンテーションでかなり過激な提案をしました。彼は基本的に、2010年に彼が姿を消す前に無効にサトシオペコードのほとんどを元に戻すというアイデアを売り込みました。

2021年にタップルートがアクティブ化されて以来、過去数年間、開発スペースは率直に言って目的がありません。ビットコインは、自己主権的な方法で世界人口のかなりの部分に実際にサービスを提供するのに十分な拡張性がなく、政府のロングアームを実際に逃れることができない非常に大規模なカストディアンやサービスプロバイダーを超えて拡張できる信頼の最小化または管理の方法でさえない可能性が高いことは誰もが知っています。

技術レベルでビットコインを理解している人なら誰でもこれを理解しています、それは議論の問題ではありません。議論の余地があり、非常に論争の的となっているのは、この欠点にどう対処するかということです。タップルート以来、誰もが、可能になる可能性のある非常に特定のユースケースのみに対処することを目的とした非常に狭い提案を提案してきました。

ANYPREVOUT(APO)は、スクリプトと入力量が同じであるロングの異なるトランザクションで署名を再利用可能にできるようにする提案であり、Lightningとそのマルチパーティバージョンを最適化するために特別に調整されました。CHECKTEMPLATEVERIFY(CTV)は、事前定義されたトランザクションと完全に一致するトランザクションによってのみコインを使用できるようにする提案であり、事前に署名されたトランザクションのチェーンを完全にトラストレスにすることで、その機能を拡張するために特別に設計されました。OP VAULTは、コールドストレージスキームの「タイムアウト期間」を有効にするように特別に設計されているため、ユーザーは、キーが侵害された場合に、さらにコールドマルチシグセットアップに送信することで、コールドストレージからの引き出しを「キャンセル」できます。

他にもたくさんの提案がありますが、要点を理解していると思います。ビットコインを根本的にスケーリングするために必要な表現力とプログラマビリティに包括的に対処しようとするのではなく、過去数年間の各提案は、スケーラビリティをわずかに向上させるか、望ましいと思われる単一の狭い機能を改善するように設計されました。これが、これらの会話がどこにも行かない理由の源だと思います。他の提案は、構築したいユースケースに対応していないため、誰も満足しません。

提案の発案者以外では、それが賢明な次の動きであると考えるのに十分な包括的なものはありません。

それが「大文字復元」の論理です。サトシが最初に設計したスクリプトの包括的な復元を押し進めて分析することで、今のところ機能の小さな拡張で十分であるかについて口論したり内輪になったりするのではなく、実際に必要な機能のスペース全体を探索しようとすることができます。

オペコード

• 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は異なるオペコードの構成を簡素化するためにさらに3つを提案しています。

• OP_CTV(またはTXHASH /同等のもの):トランザクションの特定の部分が事前に定義されたとおりに正確であることを要求するきめ細かな適用を可能にするもの。
• CSFS: トランザクション全体だけでなく、任意のデータに対して署名を検証できます。これにより、スクリプトの一部、またはスクリプトが使用するデータを、注文書にサインインして実行するように要求できます。
• OP_TWEAKVERIFY: 集計キーから個々の公開キーを加算または減算するなど、公開キーを含むシュノアベースの操作を検証します。これは、一方の当事者が共有UTXOを一方的に離脱した場合に、他の全員の資金が集約公開鍵に送信されるようにするために使用でき、離脱した当事者が注文にサインインして協力して支払う必要はありません。

WHY WE WANT TO DO THIS

レイヤー 2 は本質的に ビットコイン の基本レイヤーの拡張であり、その性質上、機能的にはベースレイヤーの機能によって制約されます。Lightning は、実際に実装する前に、CHECKLOCKTIMEVERIFY (CLTV)、CHECKSEQUENCEVERIFY (CSV)、および隔離された署名領域の 3 つの個別のソフトフォークを必要としました。

より柔軟なベースレイヤーがなければ、より柔軟なレイヤー2を構築することはできません。それを回避する唯一の近道は、純粋でシンプルな信頼できるサードパーティです。それは、私たち全員が、可能な限り大規模にビットコインと対話するあらゆる側面から取り除くことを熱望していることです。

ベースレイヤーでトラストレスに強制できる方法で、2人以上の人を1つのUTXOに安全にパックするために、注文で今すぐできないことをできるようにする必要がありますが、ビットコインスクリプトは十分に柔軟ではありません。最も基本的なレベルでは、コベナンツが必要であり、ユーザーが自分でUTXOを安全に終了しても他のユーザーの資金が危険にさらされないようにするために、スクリプトがそれらを実行するトランザクションに関するより詳細な詳細を実際に適用する機能が必要です。

大まかに見ると、これは私たちが必要とする種類の機能です。

イントロスペクション:スタック上の支出トランザクション自体に関する具体的な詳細、たとえば「この金額は、あるアウトプットでこの公開鍵に送られる」など、実際に検査できる必要があります。これにより、自分の特定のタップルートブランチを使用して自分でお金を引き出すことができますが、他の人のお金を受け取ることはできません。実行中のスクリプトは、私が去った場合、他のユーザーの公開鍵で構成されるアドレスに、他の全員が所有する正しい金額が送り返されることをコンセンサスによって強制します。

フォワードデータキャリー:たとえば、2人以上の人がいるLightningチャネルのアイデアよりもさらに進んで、誰でも好きなように行き来できる大量の人を含む単一のUTXOを構築します。どういうわけか、ほとんどの場合、マークルツリーとその根で、誰がどれだけのお金を持っているかを追跡する何らかの方法が必要です。つまり、誰かが去るとき、誰が何を受け取る権利があるかという「記録」が、他の全員のお金の変更UTXOの一部であることを保証できなければなりません。これは基本的に、イントロスペクションの特定の用途です。

公開鍵の変更: 公開鍵を集約するための変更をスタック上で検証できるようにする機能が必要です。UTXO共有スキームで目指す目標は、関係者全員との集約キーがあり、協力的でより効率的な資金移動を可能にすることです。誰かが一方的に共有UTXOを離れるときはいつでも、集約キーから個々のキーを削除する必要があります。考えられるすべての組み合わせを事前に計算しない場合、唯一のオプションは、集計から 1 つのキーを減算すると、残りの個々のキーで構成される有効なキーが作成されることを確認できることです。

HOW TO MAKE THIS SAFE: VAROPS

上で述べたように、これらのオペコードがすべて無効になった理由は、ネットワークを構成するノードを文字通りクラッシュさせる可能性のあるサービス拒否攻撃のリスクを取り除くためです。これを解決する方法があり、これらのオペコードのいずれかが使用できるリソースの量を制限します。

ビットコインスクリプトの検証で最も費用のかかる部分である署名検証に関しては、すでにそのようなソリューションがあります。これはシゴップ予算と呼ばれています。署名チェックオペコードを使用するたびに、ブロックごとに許可される署名操作の特定の「予算」が消費されます。これにより、トランザクションが個々のブロックを検証するためにユーザーに課すことができるコストに厳しい制限が設けられます。

タップルートは、単一のグローバルブロック制限を使用する代わりに、各トランザクションにトランザクションのサイズに比例した独自のsigops制限を持つように、この動作方法をシフトしました。これは、基本的に同じグローバル制限で機能しますが、個々のトランザクションが利用可能なシゴップの数に関して推論しやすくなります。

タップルートが各トランザクションに関連するsigops制限を処理する方法の変化は、これを一般化する方法を提供し、Rustyがvarops制限で提案しているものです。アイデアは、再アクティブ化された各オペコードにコストを割り当てて、各オペコードが作成する可能性のある最悪のケース、つまり検証に最も高価な計算コストをアカウントに取り込むことです。これにより、これらのオペコードはすべて、検証で消費できるリソースの数を制限するために、ある種の独自の「sigops」制限を持つことになります。また、それらを使用するトランザクションのサイズにも基づいているため、ブロックごとに暗黙のグローバル制限を追加しながら、推論の容易さを維持します。

これにより、サトシが最初にこれらのオペコードをすべて無効にする原因となったサービス拒否のリスクが解決されます。

FORWARD MOMENTUM

「これは大きすぎる変化だ」と思っている方も多いと思います。それは共感できますが、このプロジェクトの理解すべき提案として重要な側面は、すべてをやる必要はないということです。この提案の価値は、必ずしもこれらすべてを全体として元に戻すことではなく、実際に膨大なプリミティブスイートを包括的に検討し、機能面で本当に何を望んでいるのかを自問するという事実です。

それは、過去3年間、特定の機能だけを助ける小さな狭い変更をめぐって口論し、議論してきた完全なアバウトな顔でしょう。このテントは、全員が一つ屋根の下に集まり、ここからどこへ向かうべきかを総合的に見極めることができるものです。もしかしたら、これらすべてを元に戻すことになるかもしれませんし、誰もが必要と同意する機能を有効にするために必要なのはそれだけだというコンセンサスがあるため、いくつかのことをアクティブ

最終的な結果が実際にどうなるかはともかく、これからどこへ向かうのかという会話全体において、生産的な変化をもたらす可能性があります。私たちは実際に地図を描いて土地の包括的なレイアウトを得ることができ、次にどの曖昧で半分明るい道を下るかについて議論する必要がなくなります。

これは決して私たちが進むべき道である必要はありませんが、どちらを選ぶかを決める最善の策だと思います。今こそ、生産的な方法で実際に協力し始める時です。

免責事項:

1. この記事は[bitcoinmagazine』より転載したもので、すべての著作権は原作者【SHINOBI】に帰属します。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、速やかに対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。