
著者:Chakra;
ビットコインは、世界で最も早く、最も安全で、最も分散型で最高の市場価値ブロックチェーンです。ただし、1秒あたりの低いトランザクションボリューム(TPS)と限られたプログラミング機能は、大規模なアプリケーションをサポートすることが困難であると批判され、ビットコインエコシステムの開発を深刻に妨げています。ビットコインエコシステムの建設業者として、この記事では、ビットコイン拡張ソリューションの過去、現在、未来をガイドします。
この記事は、一連のビットコインスケーラビリティ記事の最初の記事であり、主にビットコインのメインネットワークの歴史に実装されたネイティブ拡張ソリューションを紹介します。次の記事では、より高いスケーラビリティを備えたオフチェーン拡張ソリューションについて説明します。乞うご期待。
ブロックサイズの制限を増やします
2010年、中本atはビットコインコアに1MBのブロックサイズ制限を導入しました。この明確な制限は、それ以来10年以上改訂されていません。
興味深いことに、中本atoshiは、コードマージのPRに「隠されている」ブロックサイズの制限を提案した理由を公に説明していませんでした。詳細な説明はありません。中本at島が去ってから数年後、コミュニティはブロックサイズの制限について深刻な意見の相違があり、より大きなブロックの需要が広範囲にわたる議論を引き起こしました。
ブロックが大きいほど、より多くのトランザクションが収容されます。コンセンサス時間が変わらないと仮定すると、ブロックが大きくなるほど、TPSが高くなります。
なぜTPSはそんなに重要なのですか?当時のトランザクションスケールで1MBブロック制限の下では、1秒あたりに完了できるトランザクションの数は3〜7トランザクションのみであり、大規模なアプリケーションでは十分ではありません。 「ビットコインのポイントツーポイントキャッシュシステム」。
ただし、より大きなブロックは、さまざまな程度に問題をもたらします。
まず、より大きなブロックには、ストレージ、コンピューティング、帯域幅などのハードウェアの要件が高く、ノード全体の運用コストが増加します。ビットコインの履歴取引データは急速に拡大しており、ネットワークと同期する時間を増やすために新しい完全なノードが必要です。これらの要件は、ユーザーの完全なノードを操作する意欲を減らし、それにより地方分権化の程度を減らします。
第二に、ブロックが大きいほど、ノード間の同期時間が長くなるほど、オーファンブロックが現れる可能性が高くなり、より頻繁にブロックの再編成をもたらし、フォーキングのリスクを高め、セキュリティを大幅に削減します。
その後、この問題はVitalikによってブロックチェーンの不可能な三角形と呼ばれました。つまり、ブロックチェーンは分散化、スケーラビリティ、セキュリティを同時に達成することはできません。ブロックが大きいほど、スケーラビリティが強くなりますが、コストは分散化とセキュリティが弱くなります。
最も重要なことは、ブロックサイズの制限を変更するにはハードフォークが必要であり、ネットワーク全体のすべてのノードを同時にアップグレードする必要があり、それ以外の場合はネットワークスプリットにつながることです。これは、分散型コンセンサスに依存するビットコインにとっては良い選択ではありません。中本佐藤の影響の下で、ハードフォークを避けることは、ビットコインの事実上の原則になったようです。
残念ながら、分割は起こりました。コミュニティ内でのコンセンサスの欠如にもかかわらず、一部の鉱夫と開発者は、クライアントのブロックサイズの制限を変更し、最終的にネットワークフォークにつながります。2016年、Bitcoin ClassicはBIP 109を使用してブロックサイズの制限を2MBに分岐しました。しかし、私たちが知っているように、鉱夫とユーザーの大多数はビットコインのメインネットに留まります。
ハードフォークによってブロックサイズを明示的に増加させる努力は失敗しました。
検疫証人
ハードフォークが受け入れられない場合、ソフトフォークをソリューションとして使用できますか?Segwitは方法の1つです。
目撃者はUTXOのロックを解除するためのバウチャーであり、長い間、目撃者はUTXOの入力スクリプトフィールドに配置され、取引を完了しています。ただし、この方法には、円形依存、サードパーティのトランザクション延性、第二党のトランザクション延性などの潜在的な問題があります。
早くも2011年、開発者はこの問題に気付き、Segwitの解決策を提案しました。しかし、当時のハードフォークの提案はサポートされていませんでした。2015年のSegwit Softフォークの提案が最終的に達成されたのはそうでした。
Segwitは、ソフトフォークを介してどのように後方互換を達成しますか?これには、主に次の2つの側面が含まれます。
-
新しいバージョンノードは、古いバージョンのノードによって生成されたブロックとトランザクションを認識して受け入れることができます。
-
古いバージョンのノードは、新しいバージョンによって導入された新しいルールと機能を認識することはできませんが、新しいバージョンによって生成されたブロックを有効であると扱います。
Segwit Soft Forkを使用すると、新しいトランザクションが空の入力スクリプトを使用し、ブロック構造に証人フィールドを追加して証人を保存できます。アップグレードの前のビットコインコアは空の入力スクリプトをサポートするため、古いバージョンのノードは新しいバージョンによって生成されたブロックを拒否しません。さらに、バージョンフィールドを使用することにより、古いトランザクションタイプが引き続き利用可能であり、ノードはバージョンに応じてさまざまな方法でそれらを処理します。
Segwitの拡張は重みの形で実装され、証人バイトの重みは1、他のデータバイトは4であるため、各ブロックの最大重量が400万に制限されます。異なるタイプのデータに異なる重みを割り当てたいのはなぜですか?常識的な考え方は、使用された場合の検証関数としてのみ機能し、長時間保管に保存する必要がないため、コストが比較的低く、体重が少ないということです。
これにより、実際には、ブロックサイズの理論上の上限が4MBに増加し(証人データのおかげで)、平均してブロックは約2MBに達する可能性があります。古いブロック構造から判断すると、これはまだブロックあたり1MB以下の中本のブロックの元の限界に準拠しています。
Taproot
OP_IFなどのビットコインのOPCODEを使用すると、時間ロック、マルチ署名などのビットコイン支出スクリプトに複雑な条件を設定できます。ただし、複雑な支出条件では、検証のために複数の入力と署名が必要であるため、ブロック負荷が増加し、すべての支払い条件を公開しながらトランザクション速度が低下し、プライバシーリークが発生します。
Taprootはマストを使用してビットコインを強化し、ユーザーはMerkle Trieを使用して支出条件を示します。各リーフノードは、支出プロセス中に支出スクリプトを表します。これにより、ブロックスペースの消費が削減され、プライバシーが増加します。
Taprootのアップグレードは、署名の集約とバッチ検証を可能にする追加の同種性特性を備えたSchnorr署名も導入し、それにより、1秒あたりの全体的なトランザクション(TPS)を増加させます。Schnorr署名の集約署名の利点は、マルチシグネチャトランザクションを検証する論理を大幅に簡素化します。以前は、ECDSAの署名がスクリプトに一致するように複数の署名をチェーンに送信する必要がありましたが、Schnorrの署名は単一の鎖の集約署名をチェーンに送信する必要があり、マルチシグネチャの支払いによるオンチェーンスペースの使用を減らす必要がありました。
複雑な契約コードは、Schnorr署名とMastを組み合わせ、Pay to Contract(P2C)コンセプトを使用して、単一のSchnorr署名で支払いをサポートする標準的なビットコイン公開キーを調整および生成することにより、Mastルートを介して送信されます。
興味深いことに、Schnorr署名の単一の署名と複数の署名がチェーンで同じように見えるため、複雑なスクリプト、複数の署名、単一の署名のロジックは、チェーンで区別できず、プライバシーをさらに強化します。
結論は
ビットコインのスケーラビリティソリューションは、分散化とセキュリティを維持しながらパフォーマンスを改善するための進化するアプローチを反映しています。
当初、ブロックサイズの増加を考慮して、低いトランザクション率の問題に直接対処しますが、ノードコストとネットワークフォークに関連する問題を引き起こし、コミュニティのコンセンサスに課題を提起します。
Segwitの導入は、ソフトフォークを介してブロック容量を最適化し、後方互換性を確保し、スプリットハードフォークを回避することにより、大きな進歩を示します。
Taprootは、MastおよびSchnorrの署名を通じてスケーラビリティとプライバシーをさらに改善し、トランザクションスペースを削減し、検証効率を向上させました。さらに重要なことに、Taprootはビットコインに複雑なスクリプトを実装し、将来の拡張の試みへの道を開くことができます。
これらの開発は、ビットコインのよりスケーラブルで強力なネットワークへの慎重で革新的な動きを強調しています。これは、グローバルな支払いシステムとしての将来にとって重要です。
ただし、これらの拡張ソリューションの影響は、「ポイントツーポイント電子キャッシュシステム」のビジョンを実現するのに十分ではありません。