V 神: ブロックチェーンを検証するとき、私たちは何をしているのでしょうか?
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
、著者：Vitalik、翻訳および校正：Elisa & A Jian、Odailyによる許可を得て転載。
しかし実際には、実際に何人のバリデータが必要なのでしょうか?独立して検証するノードが 100 個あるでしょうか?千？すべての取引をチェックするために、世界中のすべての普通の人がソフトウェアを実行する必要があるでしょうか?これらの質問に答えることが私たちの課題であり、特にシングルチェーンのnakamotoプルーフ・オブ・ワークよりも有利なコンセンサス・メカニズムを備えたブロックチェーンを構築したい場合には、これらの質問を解決することが特に重要です。
副題
なぜ検証するのか
画像の説明
ユーザーがブロックチェーンを検証することには、主に 2 つの利点があります。まず第一に、これにより、ノードは法的チェーン (つまり、コミュニティ全体に受け入れられ、正当性のあるチェーン) を決定するプロセスに最大限に参加できるようになります。一般的に、合法的なチェーンは、ビットコインの「最長の有効なチェーン」など、「最も多くのマイナーまたはバリデーターによってサポートされている有効なブロックチェーン」として定義されます。無効なチェーンは定義上拒否され、複数の有効なチェーンが競合する場合、マイナーまたはバリデータのサポートが最も多いチェーンが勝ちます。したがって、すべてのブロックの有効性を検証するノードを実行すると、どのチェーンが有効でどのチェーンが無効であるかを検出できるようになり、正当なチェーンを検出する可能性が最大になります。
しかし、実際には、ブロックチェーンを検証するユーザーにとって、より深いメリットがあります。強力な攻撃者がネットワークにプロトコルの変更 (発行の変更など) を受け入れさせようとし、採掘者の大多数がそれに賛成している場合、他の誰もブロックチェーンを検証することなく、攻撃は簡単に達成されます。そして、すべてのクライアントはデフォルトでこの新しいチェーンを受け入れます。誰もが我に返り、これに気づいたとき、彼らは調整を通じてこの新しい連鎖を拒否するために対戦相手に頼ることしかできません。しかし、一般のユーザーも検証に参加する場合、状況はまったく異なり、プロトコルを変更しようとする攻撃者は、プロトコルを変更するためにソフトウェア パッチを積極的にダウンロードするように検証済みのユーザーを説得する必要があります。
十分な数のユーザーが検証に参加している場合、誰かがプロトコルに物議を醸す変更を加えようとすると、デフォルトでは成功ではなく混乱が生じます。自然の混乱もネットワークにダメージを与える可能性があり、これを解決するにはプロトコル レベルを超えた社会的な調整が必要ですが、攻撃者の目の前にはより大きな障害が立ちはだかり、攻撃者は一撃で成功してその後立ち去ることができるという確信が持てなくなります。彼らの攻撃意欲を大幅に低下させます。大多数のユーザーが直接的または間接的な検証に参加し、攻撃者が過半数のマイナーの支持しか得ていない場合、攻撃は当然失敗し、それが誰にとっても最善の結果となります。
副題
明確な視点と協調的な視点
上記の推論のロジックは、私たちがよく聞く別の種類の推論とは大きく異なることに注意してください。チェーンがプロトコルのルールを変更する限り、それは「定義上」合法的なチェーンではないと言っています。そして重要なのは、どれだけのユーザーが新しいルールセットを受け入れるかということではなく、好みの古いルールを使用していつでもチェーンに留まることができるかということです。
この問題を「定義の観点」から議論している Gavin Andresen の例を見てください。
「ビットコイン」は、未使用の資金を使用した法的に署名された取引をブロックチェーンの形式で記録する取引台帳です。チェーンは、ハッシュが 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f であるジェネシス ブロックから始まり、あらかじめ決められたスケジュールで最も多くの Double-SHA256 Proof-of-Work を蓄積したチェーン上で 2,100 万ビットコインを発行します。
Wasabi ウォレットからの別の定義。フル ノードの価値をより簡単に説明します。
ビットコインフルノードを実行する場合、同意する正確な通貨ルールを定義できます。誰もそれをあなたに強制することはできません。したがって、経済的自由を追求する自律的なエンティティはフルノードを実行する必要があります。フルノード ソフトウェアは、独自のルールを決定した後、ビットコイン ピアツーピア ネットワーク内でルールを満たすノードを見つけることができます。これらのノードは、ルールに従って有効であると判断したトランザクションを私たちに送信し、私たちはそれを独自のルールに従って検証します。ルールを満たさないトランザクションを受け取った場合、それを無効なトランザクションとしてマークし、無効なトランザクションのソース ノードから切断できます。
副題
通貨主権を主張する
フルノードを使用すると、ビットコイン通貨のルールを定義、検証、強制することができます。
「定義」という観点では、次の 2 つの核に注目する必要があります。
最も重要なことは、自分のルールに従ったチェーンに固執することです。
あなたから見ると、同意したルールに基づいて構築されたシステム内に通貨がまだ存在していることになりますが、それではどうでしょうか?もう誰もあなたの通貨を受け入れません。取引所はそれを受け入れず、ウェブサイトでは新しい通貨の価格が高騰していると表示されるかもしれませんが、新しい通貨とは大多数のユーザーが参加するチェーン上の通貨を指し、あなたの通貨は無価値になってしまいます。暗号通貨とブロックチェーンは基本的に社会的な構築物です。誰も信じなければ、それらは無意味です。
では、この問題をどのような角度から見るべきでしょうか？この観点の中心となるのは、セキュリティを達成するために調整の問題を悪用する例としてのブロックチェーンです。
一般に、現実世界の和解問題は困難です。ただし、ほとんどの人にとって、英語が非常に複雑で不規則な綴り体系を表音綴りに変更した方が良いでしょうが、米国がメートル法 Good に切り替えた方が良いでしょうが、景気後退の場合は、すべての物価と賃金を一度に 10% 引き下げたほうがよいでしょう。実際には、これには全員が同時にこれらの変更に同意する必要があり、これを達成するのは非常に困難です。
しかし、ブロックチェーンの応用では、調整の問題が私たちの利点になりました。調整の問題によって生じる摩擦を利用して、コアプレーヤーによる不正行為を防ぎます。プロパティ X を含むシステムを構築し、プロパティ X が保持されることを保証することができます。ルールをプロパティ X から非 X に変更するには、多くの人が同意し、同時にソフトウェアを更新する必要があるからです。たとえ一人の主体が変化を強制できたとしても、その主体が変化を強制することは、敵対者が積極的に変化への抵抗を調整することよりもはるかに難しいでしょう。
文章
この観点を保持することによる特別な結果に注意を払う必要があります: フル ノードを実行する目的は、そのノード自体の利益を保護することだけではありません。議論が起きたハード フォークの場合、フル ノードを実行するユーザーは安全ですが、フルノードを持たないユーザーは安全ではありません。これは、ある種の集団免疫とも言えますが、検証する人が多ければ多いほど、全員が安全になり、たとえ一部の人だけが検証したとしても、全員がより高度な防御を得ることができます。
副題
「検証」についての徹底した議論
デフォルトは失敗の原因 > デフォルトは混乱の原因 > デフォルトは成功
ここでの「大なり記号」は、前者が後者よりも優れていることを意味します。最良のケースは攻撃が直接失敗すること、次善のケースは攻撃が混乱を引き起こし法的連鎖について全員が同意できないこと、そして最悪のケースは攻撃が成功することです。なぜ攻撃に成功するよりも混乱を引き起こす方がずっと良いのでしょうか?これは結局のところインセンティブの問題であり、混乱は攻撃者にコストを課し、攻撃が成功するという確信を失い、攻撃者が攻撃を開始するインセンティブを減少させます。当然のことながら混乱につながる環境は、攻撃者にとって、ブロックチェーン戦争に勝利し（51% 攻撃の開始に成功する）、コミュニティ全体に攻撃チェーンに従うよう説得する「世論戦争」に勝つ必要があることを意味します。これにより、単に 51% 攻撃を開始するだけで成功が保証されるよりも、攻撃がはるかに困難になり、利益も少なくなります。
検証の目標は、攻撃を、自然に成功する状態から、自然に失敗する状態 (最適)、または自然に混乱を招く状態 (準最適) にすることです。すべてのブロックを完全に検証するノードを実行し、攻撃者が異なるルールを持つチェーンをネットワークに受け入れさせようとした場合、攻撃は失敗します。一部のユーザーが完全なノードの検証を実行し、多くのユーザーが実行しない場合、攻撃により混乱が生じる可能性があります。しかし、同じ効果を達成する他の方法はあるだろうか、ということを考える必要があります。
ライトクライアントと不正行為の防止
より良いアプローチは、当然ながら、不正行為の証明を備えた軽量クライアントを使用することです。現在のほとんどのブロックチェーン ライト クライアントは、マイナーの大多数が特定のブロックをサポートしていることのみを検証し、プロトコル ルールが満たされていることを検証しません。これらのクライアントの通常の動作は、マイナーの大多数が正直であることを前提としています。物議を醸すフォークが発生すると、そのようなクライアントは自然にその傾向に従うことになるため、ユーザーは古いルールの下で少数派チェーンに留まるために積極的な措置を講じる必要があります。したがって、現在のライトクライアントが攻撃を開始する場合、攻撃者は当然成功する可能性があります。しかし、不正防止テクノロジーの場合、状況はまったく異なります。
簡単に言えば、不正行為の証明は次のように機能します。一般的に、ブロックチェーン内の 1 つのブロックは、ブロックチェーンの「状態」のごく一部 (アカウント残高、スマート コントラクト コードなど) のみを指します。フル ノードがブロックを処理し、それが無効であることが判明した場合、データ パケット (つまり、不正行為の証拠) を生成し、それをライト クライアントにブロードキャストできます。データ パケットには、ブロックとそのブロックを処理するのに十分なデータのみが含まれており、データ パケットを受信した後、ライト クライアントはチェーン上の他のデータを必要とせずに、単独でブロックを検証できます。
この手法はステートレス検証と呼ばれることもあり、クライアントは完全なブロックチェーン状態データを記録せずにブロック ヘッダーのみを記録することができ、他のノードから任意の状態エントリのマークル証明を要求することでリアルタイムで検証できます。
断片化
この手法の利点は、ライト クライアントがアラートの受信後に 1 つのブロックのみを検証することです (アラートも検証可能であり、ライト クライアントが誤ったアラートを見つけた場合、ノードのアラートのリッスンを停止できます)。そのため、通常の状況では、ライトクライアントは軽量のままで、どのブロックが大多数のマイナーまたはバリデーターによってサポートされているかを確認するだけです。ただし、特殊なケースでは、大多数の人が配置されているチェーンにライトクライアントが受け入れないブロックが含まれている場合、少なくとも 1 つの正直なフルノードが問題のあるブロックを検証している限り、それが無効であることがわかり、ネットワーク内の他のノードもそれを拒否するような、不正行為の証拠をブロードキャストします。
副題
断片化
さらに、もう 1 つの点が非常に重要です。シャーディング システムでは、ブロック生成 (検証だけでなく) のしきい値が非常に低く、家庭用ラップトップでも実行できます。ネットワークの中核は高性能ハードウェアに依存していないため、反対派が少数派であることの閾値が十分に低くなり、多数派が支配するプロトコルが「自然な攻撃の成功」となることがより困難になります。攻撃者による「状態」（攻撃に他の人を強制的に従わせる）。
これは、現実世界での監査の意味でもあります。誰もが常にすべてを検証しているわけではありませんが、まず、特定の部分をチェックするのに十分な人数がいて、エラーが必ず見つかること、そして第 2 に、エラーがチェックされると、そして、どこが間違っていたのかが誰でもはっきりとわかります。
そうは言っても、長期的には、ブロックチェーンは間違いなくこの点でさらに前進する可能性があります。進歩の源の 1 つは ZK-SNARK (または「有効性証明」) です。ZK-SNARKs (または「有効性証明」) は、ブロック作成者がブロックが任意の複雑な有効性条件を満たしていることをクライアントに証明できるようにする効率的で検証可能な暗号証明です。正当性証明は、欺瞞を見つけるためにインタラクティブなゲームに依存しないため、不正証明よりも強力です。もう 1 つの重要な技術は、完全な開示内容を持たないブロックを検出できる「データ可用性チェック」です。データの可用性の証明は、いくつかのセキュリティの仮定に依存しますが、この仮定は非常に保守的です: ネットワーク内には、利用可能な誠実な (「合意に従う意思がある」) ノードがまだ少数存在します。良いニュースは、これが正直なバリデータの最小数は少なく、攻撃者の数が非常に多い場合でも、要件を引き上げる必要はほとんどありません。
副題
ここで、「自然なカオス」パターンの最も強力な結果を見てみましょう。51% の攻撃がそれ自体を攻撃し始めます。現在の多くのコミュニティでは、51% 攻撃が発生して攻撃者が勝利した場合、51% 攻撃チェーンは正当なチェーンになります。この仕様は全員が厳密に従っています。イーサリアム クラシックに対する最近の 51% 攻撃はこの点を示しています。攻撃者は 3,000 ブロック以上をロールバックし、その過程で二重支払い攻撃により 807,260 ETC を盗みました。イーサリアムの 2 つの古典的なクライアントのうちの 1 つ (OpenEthereun) は技術的に攻撃チェーンの歴史的な高さに戻ることができないため、Geth ノードは攻撃チェーン上で実行できますが、OpenEthereum は元のチェーン上でしかトラップできません。
この攻撃は確かに混乱を引き起こしたと言えますが、それはイーサリアム クラシック コミュニティによる意図的な設計ではなく、偶然でした。その後、コミュニティが（より長い）攻撃チェーンを正当なものとして受け入れることを選択したのは残念です。イーサリアムクラシックのツイッターアカウントは、これを「当初の意図と同様にプルーフ・オブ・ワークの厳守」と呼んでいる。したがって、このコミュニティ規範は攻撃者が勝つのに積極的に役立ちます。
しかし実際には、法的チェーンの定義については別の合意に達することができます。たとえば、ブロックに 100 を超える子孫ブロックがある場合、その正当性を覆すことはできないというルールを確立することができます。または、ファイナリティのあるプルーフ オブ ステーク (イーサリアム 2.0 など) では、ブロックがファイナライズされると決してロールバックされないというルールが適用されます。
画像の説明
このアプローチも成長する可能性を秘めています。混乱を引き起こすトランザクションを特別に検閲するために、51% 攻撃を作成することもできます。適時性検証ツールに関する研究も、あらゆる種類の攻撃を自然失敗へと誘導しています。それでも、適時性検証ツールはオフラインのノードやネットワーク接続が悪いノードを支援できないため、多少の混乱は残るでしょう。
結論は
不変性を重視するブロックチェーン コミュニティにとって、ネットワークがどれだけ前にトランザクションを受け入れたとしても、誤ってロールバックされる可能性がある場合、ロールバックを制限するこの措置は良い選択であると言えます。不変であると主張することはできません。もちろん、極端な場合には BTC や ETC でもロールバックは限られていると思いますが、攻撃が数週間分のブロック履歴をロールバックしようとした場合、コミュニティは受信者チェーンへの攻撃を拒否するために積極的なユーザーの参加を必要とするソフト フォークを開始する可能性があります。しかし、この措置のより明確な合意と正式化はさらに一歩前進するでしょう。
副題
結論は
それでは、この物語は私たちに何を教えてくれるのでしょうか？まず、ソーシャル コラボレーションの正当性と、「1-of-N」信頼モデルを前提とした間接検証の正当性を受け入れる場合、つまり、特定の参加者を仮定するのではなく、ネットワークに常に正直な参加者が存在すると仮定します。 (Infura など) 常に正直であれば、よりスケーラブルなブロックチェーンを作成できます。
