ヴィタリック・ブテリンは、ユーザーがイーサリアムをエンドツーエンドで個人的に検証する必要性を軽視した2017年のツイートにもはや同意しないと述べました。
今週、彼はネットワークのアーキテクチャがより軽量でモジュール化されるにつれて、セルフホスト型検証を譲れない脱出口として扱うべきだと主張しました。
ブテリンの当初の立場は、ブロックチェーンがチェーン上で状態にコミットすべきか、それとも状態を「暗黙的」なものとして扱い、順序付けられたトランザクションを再生することによってのみ再構築可能とすべきかという設計論争から生まれました。
イーサリアムのアプローチは、各ブロックヘッダーに状態ルートを配置し、マークルツリー形式の証明をサポートすることで、ユーザーが正直多数派の仮定の下でチェーンのコンセンサスの妥当性を受け入れる限り、すべての履歴を再実行することなく、特定の残高、コントラクトコード、またはストレージ値を証明できるようにします。
新しい投稿で、ブテリンはこのトレードオフを実際には不完全なものとして再構成しました。なぜなら、ユーザーはフルチェーンの再生か、RPCオペレーター、アーカイブデータホスト、証明サービスなどの仲介者を信頼するかの選択を迫られる可能性があるためです。
彼は2つの変化に変更を結びつけました:実現可能性と脆弱性です。
実現可能性について、ブテリンはゼロ知識証明が「文字通りすべてのトランザクションを再実行する」ことなく正確性をチェックする道を提供すると書きました。
2017年、彼はこれがイーサリアムを検証を手の届く範囲に保つために低容量へと押しやるだろうと主張しました。
この変化が重要なのは、イーサリアムの公開ロードマップがますますZKを検証可能性のプリミティブとして扱い、ethereum.orgがゼロ知識証明を、検証者が計算しなければならないものを減らしながらセキュリティ特性を保持する方法として位置付けているためです。
「ZKライトクライアント」の方向性に関する作業も、デバイスが常時オンラインのゲートウェイを信頼するのではなく、コンパクトな証明を使用して同期できるモデルを指し示しています。
脆弱性について、ブテリンはクリーンな脅威モデルの外にある障害モードを列挙しました:P2Pネットワーキングの劣化、長期稼働サービスのシャットダウン、「正直多数派」の実質的な意味を変えるバリデーター集中、そして「開発者に電話する」を最後の砦に変える非公式のガバナンス圧力です。
彼はTornado Cashをめぐる検閲圧力を、仲介者がアクセスを狭める方法の例として引用し、ユーザーの最後の手段は「チェーンを直接使用する」ことであるべきだと主張しました。
そのフレーミングは、プロトコルの「硬直化」への推進の中で、イーサリアムのベースレイヤーを強化し、変動を制限することに関するより広範な議論と連動しています。
ブテリンの語りでは、「山小屋」はデフォルトのライフスタイルではありません。
それは信頼できる代替案であり、インセンティブを変えるものです。なぜなら、ユーザーが退出できるという知識が、単一のサービス層のレバレッジを減らすからです。
この議論は、イーサリアムが通常のノードに保存することを期待されるものを減らす一方で、ネットワークの検証ストーリーがペースを保つ必要がある時期に着地しています。
実行クライアントは部分的な履歴の失効に向かって進んでおり、イーサリアム財団は、ユーザーがマージ前のブロックデータを削除することで約300〜500 GBのディスク使用量を削減でき、2 TBディスク上でノードを手の届く範囲に置くことができると述べています。
同時に、ライトクライアントはすでに低リソースデバイス向けに最適化された正式化された信頼モデルを反映しており、約1.1日ごとに選択される512のバリデーターの同期委員会に依存しています。
これらのパラメータは、ライトクライアント検証を大規模に実行可能にします。
しかし、それらはまた、状況が悪化したときに正しいデータの利用可能性と適切に動作するリレーを中心にユーザーエクスペリエンスを集中させます。
イーサリアムの長期的な「ステートレス」作業は、ブロック検証を維持しながら、ノードが大きな状態を保持する必要性を減らすことを目指しています。
Ethereum.orgは「ステートレス」が誤った呼び名であると警告し、状態失効を含む研究段階にある、より強力な設計とより弱い形態を区別しています。
Verkleツリーはそのプラン内に位置しています。なぜなら、それらは証明サイズを削減し、大きな状態をローカルに保存せずに検証する重要な実現ステップとして位置付けられているためです。
ストレージ負担がより外側にシフトし、専門の履歴ホストや他のデータネットワークに移るにつれて、セキュリティストーリーは誰がすべてを保存できるかについてではなく、誰が独立して正確性をチェックし、デフォルトパスが失敗したときに必要なものを取得できるかについてになります。
| 変更内容 | 検証にとっての重要性 | 具体的なパラメータまたは数値 |
|---|---|---|
| 実行クライアントでの部分履歴失効サポート | ローカルストレージの削減は、取得と検証パスが開いたままでない限り、外部履歴の可用性への依存を高める可能性がある | 約300〜500 GBのディスク削減、2 TBディスク上で「快適」 |
| PoSライトクライアント信頼モデル | 低リソース検証は、ピアまたはサービスを通じた委員会の署名とデータの可用性に依存する | 512のバリデーターの同期委員会、約1.1日ごとにローテーション |
| ステートレスクライアントの実現要素としてのVerkleツリー | より小さな証明は、保存された状態が少ない検証をより実用的にすることができる | ロードマップのフレーミングはVerkleツリーをステートレス検証目標に結びつける |
| ステートレスロードマップの区別 | 状態失効などの研究項目から短期的なアプローチを分離する | 弱いステートレス対強いステートレスの用語 |
| L1 zkEVMセキュリティ基盤に関するEFの作業 | 証明システムの厳密性と安定性がイーサリアムの基本セキュリティストーリーの一部になる | 安定化と形式的検証の準備への重点 |
今後12〜36か月間、実際的な問題は、イーサリアムがより多くのストレージ負担を外部化するにつれて検証が外側に広がるのか、それとも信頼が新しいサービスのチョークポイントの周りに集まるのかということです。
1つの道は、ウォレットとインフラストラクチャが「RPCを信頼する」から「証明を検証する」へシフトする一方で、証明生成が複製が難しい最適化されたスタックの小さなセットに統合され、依存関係が1つのクラスのプロバイダーから別のクラスに移動することです。
別の道は、証明ベースの検証が一般的になり、冗長な証明実装とツールにより、エンドポイントが検閲、劣化、または消失したときにユーザーがプロバイダーを切り替えたりローカルで検証したりできるようになり、軽量検証フローを目指す取り組みと一致することです。
3番目の道は、プルーニングとモジュール性が検証UXよりも速く進行し、停止または検閲イベント中にユーザーが利用できる実行可能なオプションが少なくなることです。
それは「山小屋」をネットワークの狭い部分に対してのみ運用上現実的にするでしょう。
ブテリンは山小屋をイーサリアムのBATNAとして位置付けました。めったに使用されませんが常に利用可能です。なぜなら、自立オプションの存在が仲介者によって課される条件を制約するからです。
彼は、そのフォールバックを維持することがイーサリアム自体を維持することの一部であると主張して締めくくりました。
「ヴィタリック・ブテリンが2017年以来の最大の設計ミスを認める – あなたのイーサリアムはリスクにさらされているのか?」という投稿は、CryptoSlateに最初に掲載されました。


