柔軟な取引

最近、ある質問を頻繁に受けるようになりました。質問は、Segregated Witness ソリューションに関するもので、具体的にはハードフォーク ベースのバージョンはどうなるかということです。

Segregated Witness（略して「SegWit」）は非常に複雑です。これは、かなり多くの、まったく異なる、関連のない問題を解決しようとしており、下位互換性のある方法でそれを実行しようとしています。これは小さな問題ではありません!

それで、SegWit はどのような問題を解決しようとしているのでしょうか?この情報は、特典文書に記載されています。

1. 延性修復

2. sighash 操作の線形スケーリング (つまり、署名に必要なハッシュ操作の 2 倍、署名に必要な操作の 10 倍)

3. 入力値の署名

4. Pay to Script Hash (P2SH) トランザクション標準によるマルチシグのセキュリティ強化

5. スクリプトバージョン

6. UTXOの増加を抑える

7. コンパクトな詐欺証明

前述のように、SegWit は下位互換性のある方法でこれらの問題に対処しようとします。この要件が存在するのは、SegWit の作成者が設定したためです。これは、ソフトフォークを使用してプロトコルのアップグレードを推進することを望んでいるためです。この記事では、これがこれらの問題を解決する最善の方法であるかどうかという疑問に答えようとします。

まず、展性の問題は、ファンド所有者とブロックを採掘するマイナーがトランザクションを構築した時点からトランザクションが開始され、展性の問題により、展性の変更は有効なトランザクションとみなされますが、トランザクション識別子 (TX-id) が変更されていることです。始める前に、トランザクション データ構造を見てみましょう。

トランザクション データ構造を今見てみると、いくつかの問題があることに気が付くでしょう。

サトシ・ナカモトが設計したオリジナルのトランザクション形式には、4 バイトのバージョン番号が含まれていました。この設計アプローチは業界では非常に一般的であり、データ構造内の任意のフィールドを変更する必要がある場合に新しいバージョンが定義されるという方法で採用されています。ビットコインの場合、まだそこに到達しておらず、バージョン 1 のままです。

ビットコインは代わりに、より小規模で、ある程度下位互換性のある変更を行っています。たとえば、CHECKSEQUENCEVERIFY 機能は、古いクライアントのデータを壊すことなくデータを追加する方法として、シーケンス フィールドを再利用します。ちなみに、この特定の変更 (BIP68 で詳細が説明されています) は、1 より大きいトランザクション バージョン番号に依存しており、すべてのクライアントが標準トランザクションをチェックし、バージョン 1 のみが標準であると述べているため、主要なクライアントでは下位互換性がありません。

バージョン番号付きの設計は、設計者が変更を処理するためにハードフォークを使用するつもりであることを意味します。新しいクライアントは、新しく設計されたデータ構造を解析する方法を知る必要があることは明らかです。したがって、1 つのアイデアは、バージョン番号を変更することです。これにより、古いクライアントは、この新しいトランザクション バージョンを解析できないことを認識します。操作を維持するには、全員がこの新しいトランザクション バージョンをサポートするクライアントにアップグレードする必要があります。

バージョンを変更する理由を見てみましょう。混乱を招く可能性のある項目をいくつか赤で強調表示しました。最も特別なのは、トランザクション内でこれらの番号が 3 つの異なる互換性のない形式で保存されることです。これは必ずしも大きな、そして決定的なバグではありません。

取引はビットコインの所有者によって暗号的に署名されるため、他の人は所有者がそのアドレスから実際にビットコインを転送できることを確認できます。署名は TX-in-script に保存されます。

暗号マニアは、教科書の知識に反する奇妙なことに気づいたかもしれない。つまり、デジタル署名は署名するオブジェクトの外部に配置する必要があります。これは、デジタル署名が改ざんから自身を保護するためです。しかし、署名だけでこの変化が起こります。したがって、署名は署名するものの外部に保存する必要があります。 （翻訳者注：つまり、デジタル署名は署名するデータの外側に配置する必要があります。これは、デジタル署名は署名されたデータが変更されるのを防ぐことができますが、署名自体はデータを変更するためです。したがって、署名は署名されたデータの外側に配置する必要があります）

ビットコインの作成者は、トランザクションの署名が実際にどのように行われるかについて「賢い」方法を採用したため、署名は実際にはトランザクションの外部にある必要はありません。ほとんどの場合、それは実際に機能しました。しかし、私たちはそれが完璧に機能することを望んでいます。なぜなら、現在これらの設計はあまりにも「巧妙」であり、ひどいスケーリングの問題を引き起こし、人々はそれによってお金を失っているからです。

SegWitについてはどうですか?

SegWit は実際にはこれらのプロジェクトの 1 つの問題のみを解決します。トランザクションから署名を削除します。 SegWit はビットコイン取引に関するその他の問題を解決せず、取引後にバージョンを変更することもないため、古いクライアントは SegWit の本質を理解できないことがほとんどです。

古いクライアントは、トランザクションの SegWit タイプをチェックできなくなります。これは、SegWit の作成者が、実際のデータが「トレーラー」に移動されたときに、古いクライアントが「トレーラー」を無視することを知っていたため、SegWit トランザクションを「すべて OK」とラベル付けしただけだからです。 (翻訳者注: Segregated Witness の作者は、古いクライアントがトレーラーをチェックしないことを承知の上で、車に「すべて正常」というラベルを貼るのと同じような方法で、実際のデータを車の後ろのトレーラーに移動するように設計しました)

SegWit (Segregated Witness) は、トランザクションのデータ構造を変更せずに維持し、トランザクションのデータ構造を修復しようとします。両方を同時に実行することはできないため、競合が発生し、理想的な状況ではなくなり、ハッキング攻撃が発生することが予想されます。

問題は、SegWit によって「技術的負債」が増えることです。技術的負債とは、短期的には実装が容易でも、長期的には悪影響を及ぼす設計やアーキテクチャを選択した開発チームが負う負債を指すソフトウェア用語です。ここでの「負債」という言葉は比喩的に非常に正確であり、時間の経過とともに、トランザクションを使用するすべての人が、正しく操作するためにこの欠陥を理解する必要があります。これは利息を支払うことに非常に似ています。

ソフトフォークでは、古いクライアントはトランザクションを検証したり、完全に解析したりすることができなくなります。しかし、これらの古い顧客自身は、適切な検証を行っていると考えています。

これを改善することはできますか?

トランザクション データ構造を一度変更して将来性を高め、時間の経過とともにスケーラビリティの問題などの問題を修正する方法を提案したいと思います。この新しいデータ構造のおかげで、SegWit は他のすべての些細な問題を修正して解決できることがわかりました。

私は次のようなアップグレードを提案します:

柔軟な取引

先週末、私はトランザクションを読み取り、それを Bitcoin 用に私が考案した新しい形式で書き出す小さなアプリケーション (ソース コードはこちら) を作成しました。これは私が他のプロジェクトでしばらく使用してきたアイデアに基づいていますが、これは最初のオープンソース バージョンです。

基本的な考え方は、トランザクションを変更して、JSON、HTML、XML などの最新のシステムに似たものにすることです。これは「タグ」ベースの形式であり、クローズドな「バイナリ BLOB」形式に比べてさまざまな利点があります。

たとえば、HTML のタグと同じように新しいフィールドを追加した場合、古いブラウザではそのフィールドが無視されるため、下位互換性が保たれ、将来のアップグレードにも適したものになります。

その他の利点;

• 延性の問題を解決すれば、それは些細なこととなるでしょう。

• 「タグ」ベースのシステムを使用すると、未使用の値やデフォルト値の書き込みをスキップできます。

• この変更を行っているため、トランザクションで 3 つの異なる型の代わりに var-int (可変整数) を使用してデータをエンコードできます。

• 新しいタグ (ScriptVersion など) を追加した後は、トランザクション データ構造をさらに変更する必要はありません。すべての古いクライアントは、引き続きすべての既知のデータを解析できます。

• 実際のトランザクション時間は平均より約 3% 短くなります (200K を超えるトランザクションで計算)

• SegWit は多くの技術的負債を追加しましたが、私の「柔軟なトランザクション」ソリューションでは償却される技術的負債がそれほど多く発生しません。

「柔軟なトランザクション」ソリューションは一般的に次のようになります。

Flexible Transaction では、JSON のようなタグのリストを使用することを提案しています。 「名前:」「値」。これにより、コンテンツは非常に柔軟かつ拡張可能になります。 Flexible Transaction では、単なるテキストではなくバイナリ形式を使用します。未使用のタグがスキップされることに注意してください。 NLockTime と Sequence は使用されないため、トランザクションではスキップされます。

最大の変更点は、TX-in-script (別名、証人データ) がトランザクションの最後に移動されることです。ウォレットがこの新しいトランザクション タイプを生成すると、最後に証人データが追加されますが、トランザクション ID は証人データの前で終わるデータをハッシュすることによって取得されます。

証人データには通常、公開鍵と署名が含まれます。フレキシブル トランザクション スキームでは、まったく同じデータ セットに署名することで署名が完了し、ハッシュ アルゴリズムを使用して TX 入力が生成されます。スケーラビリティの問題を解決します。誰かがトランザクションを変更すると、署名は無効になります。

私はテスト アプリケーションを使用してこれをテストし、最近の 187,000 件のトランザクションを実行し、この変更がトランザクションのサイズにどのような影響を与えるかを確認しました。

• トランザクション サイズは平均 1,712 バイトから 1,660 バイトに減少し、平均サイズは 333 バイトから 318 バイトに減少しました。

• 確認後は、トランザクションをさらに合理化できます (署名を削除)。プルーニング後、サイズは平均 450 バイト、中央値では 101 バイト減少しました。

• SegWit (Segregated Witness) とは対照的に、このアップグレード後、すべてのクライアントのトランザクション サイズは小さくなります。

• 署名が削除されると、トランザクションとブロックのサイズは最大 75% 削減されます。
  

壊れた OP_CHECKSIG スクリプト コマンド

実際にソースでのスケーラビリティの問題を修正するには、この命令を修正する必要があります。ただし、スクリプト言語のバージョン 2 を作成することを決定するまで、元のスクリプトを変更することはできません。

この変更はバージョン 2 を実行するのに適した時期ではありませんでした。同時に、取引自体の新しい形式も開始していたため、バージョン 2 を実行するのは無謀だったでしょう。 (同時に変更が多すぎると、必ず問題が発生します)。

つまり、フレキシブル トランザクション スキームを実際に機能させるには、スクリプト内でこれまで使用したことのない NOP コードを使用し、基本的に OP_CHECKSIG と同じように動作させる必要がありますが、署名方法を過度に複雑にするのではなく、TX-ID の作成にも使用するのとまったく同じトランザクション フィールドに署名するように定義するだけです。 (上記の表の右端の列を参照してください)。

この新しいオペコードは比較的簡単にコーディングでき、スクリプトの将来のバージョンでスクリプトに導入された問題を非常に簡単に修正できるようになります。

それで、これは SegWit とどう違うのでしょうか?

まず、トランザクションの新しいバージョンを導入しても、現在のバージョンのサポートが停止されるわけではありません。したがって、これらすべては完全に下位互換性があり、クライアントは古いバージョンの古いトランザクション形式を使用して引き続き取引できます。もちろん、いくつか問題はありましたが、結局誰も行き詰まることはありませんでした。

トランザクションにタグ付き形式を使用すると、プロトコルをアップグレードするための 1 回限りのハードフォークが実行され、将来のシステムへの影響を大幅に抑えながら、より多くの変更が可能になります。また、SegWit (Segregated Witness) との類似点もあり、結局のところ、両者は同じ目標を目指しています。ただし、SegWit は既存のフィールドを再利用することで静的ストレージ形式を適応させようとしますが、柔軟なトランザクションの提案では、多数の矛盾する概念を排除した一貫性のあるシンプルな設計を提案しています。

最も重要なことは、フレキシブル トランザクション ソリューションが導入されてから何年も経った今でも、同じ一貫した概念を使用して、タグ付けシステムのメリットを継続的に活用し、まだ考えもしなかった、または発見もしていない問題を拡張して修正できることです。

SegWit と同様に、同じ (ブロック) スペースにさらに多くのトランザクションを収容でき、署名 (証人部分) はセキュリティ上の問題を引き起こすことなくフルノードによって合理化できます。これら 2 つのソリューションは同じです。 SegWit (Segregated Witness) が実装していないのは、未使用の機能がスペースを占有しないことです。したがって、トランザクションが NLockTime を使用しない場合 (ほぼ 100% が使用します)、SegWit では依然としてスペースを占有しますが、この提案されたソリューションではスペースを占有しません。取引サイズが小さくなるため、手数料も低くなります。

サイズの面では、SegWit はスペースを 60% 増やすことを目標としています。署名を削除することでオーバーヘッドを削減します。私のテストでは、フレキシブルトランザクションによりスペースが 75% 増加しました。

SegWit (Segregated Witness) は、ブロックに保存されたデータを変更する方法についても説明します。 Merkle プロセス ツリーに追加のブランチを作成します。フレキシブルトランザクションは、基本的に SegWit と同じ方法を使用して同じブロック適用の問題を解決します。つまり、Merkle プロセス ツリー ソリューションも採用できるということです。変更は発生していません。

この記事で上記で述べた利点のリストには、SegWit (Segregated Witness) の作成者が述べた利点も含まれています。これらの利点は、それ自体ではまったく無関係であり、それぞれが問題に対して非常に独立した解決策を持っていることがわかります。厄介なのは、古い顧客からのリクエストがすべて 1 つの「修正」に押し付けられることです。

それぞれ確認してみましょう:

延性修復

この新しいバージョンのトランザクション データ構造を使用すると、既知のスケーラビリティの問題はすべて解決されます。

sighash 操作の線形スケーリング

これが解決しようとしている問題は、この bitcointalk スレッド (https://bitcointalk.org/?topic=140078) で説明されています。

この議論の結果、SigOps バリアントが導入されましたが、これはすぐに最適ではない解決策であることが判明しました。 BIP109 には、sig-hash-bytes (ノードの総数を計算する) と呼ばれるより優れたソリューションがあります。これは、ハッシュ化が検証プロセスの中で最もコストのかかる部分であるという事実に基づいています (ハッシュ化は署名検証の一部でもあることに注意してください)。

このソリューションでは、1M ブロックでは最大 650MB のハッシュしか計算できないため、検証時間は 5 秒しかかからないという明確な結論が示されています。これは、ブロック検証時間が特に長くならないようにするための保護です。

これは適切なバランスであり、最も極端なトランザクションが発生したときにブロックの検証を確実にするために、1 MB ブロックあたり 650 MB のハッシュが実行されます。

これは解決する必要のない問題のように思えます。協定を修正すると予期せぬ結果をもたらす可能性があり、それは過剰反応となるだろう。

入力値の署名

この提案に含まれています。

ペイ・トゥ・スクリプト・ハッシュ（P2SH）トランザクション標準によるマルチ署名セキュリティの強化

この記事で概説した柔軟なトランザクション提案により、後で SegWit に多くの追加変更を簡単に追加できるようになります。この変更もその一つです。

要するに、SegWit では、より大きなハッシュを使用して SegWit に安全な変更を加えることは、SegWit でのみ機能します。これは、SegWit ではトランザクションのバージョン管理の問題が解決されず、処理自体が簡単でほとんど価値がないためである。

柔軟なトランザクション ソリューションを使用すると、このような変更は将来いつでも最小限の影響で行うことができます。

スクリプトバージョン

これはバージョン管理バイトのみを導入することに注意してください。実際にはスクリプトの新しいバージョンが導入されるわけではありません。

これは、このようなバージョン タグを追加する方がクリーンで便利で、邪魔にならないため、柔軟なトランザクション スキームのタグ形式が SegWit で採用されている静的ストレージ形式よりも優れていることを示す良い例です。新しいタグを追加するだけで、デフォルトでバージョン 1 になり、タグのないトランザクションの古いバージョンとの一貫性を保つことができます。

削除できないため、すべての HTML ページに「body background=white」を含める必要があると想像してください。これが現在 SegWit が行っていることです。ただし、実際には現在のところ変更はサポートされていません。

UTXOの増加を抑える

これを注意深く読んでみることをお勧めします。これは非常に興味深い技術であり、多くの人がそのアイデアを完全に把握したり理解したりできないことは確かです。結局のところ、SegWit によってより多くのクライアントにサービスを提供できなくなるため、UTXO データベースは成長を回避できると彼らは主張しています。

このような解決策にどう対応したらいいのかさえ分かりません。これは、大切なものを無駄にしてしまう典型的な例です。

データベース技術は過去 20 年間で大きく成熟しましたが、今日の無料およびオープン ソース データベースの機能と比べると、その進歩はほんのわずかです。確かに、UTXO データベースは通常の SQL データベースと若干互換性がありません。しかし、長期的には、クライアントに別の場所に行くように指示することは、長期プロジェクトでは行われません。

コンパクトな詐欺証明

繰り返しますが、これは SegWit には含まれておらず、SegWit の基礎を提供するだけです。柔軟なトランザクションも同じ基盤を提供し、ここでは両方のソリューションは同じです。

SegWitでは提供できないものを私たちが提供できるのでしょうか?

1. トランザクションはスケーラブルになります。今後の改良も便利です。

2. 取引サイズが小さくなります。使用する機能が少なくなり、必要なスペースも少なくなります。

3. エンコードには 3 つの整数型ではなく 1 つの整数型のみを使用します。

4. 技術的負債を取り除き、簡素化しました。 SegWit (Segregated Witness) はその逆のことを行います。

要約する

SegWit (Segregated Witness) には、優れたアイデアと必要な修正がいくつかあります。エッセンスを取り、不要な部分を破棄することは可能ですが、ハードフォークが必要になります。この記事では、これらの利点がかなり大きく、価値があることを示しています。

ラベルデータ構造を導入しました。概念的には JSON や XML と同じくらい柔軟ですが、提案されたスキームはコンパクトで高速なバイナリ形式です。柔軟なトランザクション データ形式を採用することで、将来の多くの改善や革新を一貫性とクリーンさを保ち、後の段階でも SegWit よりも下位互換性を保ちながら、長期間にわたって維持できるようになります。 SegWit が個別に修正しようとしている基本的な事項は、すべて一度に実行できることがわかります。これにより、システムとしての Bitcoin のリスクが低くなります。

SegWit が設計されてから 1 年が経過しましたが、ソフトウェアのリリースには依然として問題や遅延が発生しており、下位互換性を維持するという要件を放棄することについて議論する時期が来ていると思います。

柔軟なトランザクション アップグレードを導入すると、トランザクション設計がスケーラブルになるため、大きなメリットが得られます。一度ハードフォークを実行すると、将来的にソフトアップグレードを実行できるようになります。

柔軟なトランザクションにより、システム全体で必要な変更の量が削減されます。これはフルノードに限ったことではなく、多くのツールやウォレットがトランザクションの作成と解析に共有ライブラリに依存していることを考えると特に当てはまります。

プロトコルの安定性を懸念する人は、この記事で提案されている柔軟なトランザクションのアップグレードを検討する必要があります。アップグレード後の障害のリスクは、SegWit の場合よりも桁違いに低いためです。技術的負債がないので、将来的にはより優れた革新が可能になります。

フレキシブルトランザクションはトランザクションサイズが小さく、SegWit よりも大幅なスペース節約が可能です。

(校正をしてくださった@vattenに感謝します)