Vitalik：ローカルノードに焦点を当てたスケーリングロードマップの最適化案

著者:ヴィタリック、イーサリアムの創設者。 翻訳:ゴールデンファイナンス小州

L1ガス上限の引き上げに対する最も一般的な批判は、ネットワークの安全性に関する懸念の他に、フルノードの運用がより困難になるという点です。特に「フルノードの解放」を中心としたロードマップの背景において、この問題を解決するにはフルノードが存在する意義を理解する必要があります。

従来の見解では、フルノードはチェーン上のデータを検証するために使用されます。もしこれが唯一の問題であれば、ZK-EVMはL1のスケーリングを解放することができます：唯一の制約は、ブロックの構築と証明のコストを十分に低く保ち、両者が1 of nの検閲耐性を維持しつつ、競争的な市場を形成できることです。

しかし現実には、これは唯一の考慮事項ではありません。もう一つの重要な要素は：**フルノードを運営することで、信頼を必要とせず、検閲に対抗し、プライバシーを保護した方法でオンチェーンデータを読み取ることができるローカルRPCサーバーを持つことができるということです。**この記事では、現在のL1スケーリングロードマップを調整してこの目標を達成する方法について議論します。

1、なぜZK-EVM+PIRによる信頼性のないプライバシーに満足しないのですか？

先月発表したプライバシーロードマップでは、短期的にはTEEs + ORAMの採用を、長期的にはPIR技術への移行を提唱しています。 HeliosおよびZK-EVM検証と組み合わせることで、ユーザーは外部RPCに接続するときに(i)によって取得されたチェーンデータが正しいことを完全に確信(ii)、データのプライバシーが保護されます。 これは疑問を投げかけます:なぜそこで止まらないのですか? これらの高度な暗号化スキームは、セルフホストノードを時代遅れにしますか?

これに対して私にはいくつかの反応があります：

--完全に信頼しない暗号学的ソリューション（例：単一サーバーPIR）のコストは非常に高い。現在のオーバーヘッドは非現実的に高く、何度も効率を最適化しても高価格を維持する可能性があります。

--**メタデータのプライバシー問題。**IPアドレスのリクエスト時間、リクエストパターンなどのメタデータ自体が大量のユーザー情報を暴露する可能性があります。

--**脆弱性の審査：**少数のRPCプロバイダーが支配する市場構造は、強力なユーザーの禁止または審査の圧力に直面します。多くのRPCプロバイダーは、特定の国を完全に遮断し始めています。

したがって、個人ノードの運用の便利さを引き続き保証することには価値があります。

2. 短期的な優先事項

EIP-4444の優先的な全面展開を行い、最終的には各ノードが約36日分のデータのみを保存することを実現します。これにより、ハードディスクのスペース要件が大幅に削減されます——現在、ノードの運営を妨げている主要な障害です。その後、ノードのストレージ要件は次のもののみを含むことになります：(i)状態データ、(ii)状態マークルブランチ、(iii)36日分の履歴データ。

分散型の歴史データストレージソリューションを構築し、各ノードが少量の超過歴史データを保存します。エラーレジスタ技術を使用して信頼性を最大化します。これにより、「ブロックチェーンの永久保存」特性を保証し、中央集権的な供給者に依存することなく、ノードオペレーターに重い負担をかけることがありません。

**ガス価格戦略を調整して、貯蔵コストを増やし、実行コストを削減します。 **次の操作のガスコストの増加に焦点を当てます:新しいストレージスロットに対してSSTOREを実行する(i)、コントラクトコードを作成する(ii)、 (iii) ETHをゼロ残高/ゼロノンスアカウントに送金します。

3. 中期目標:ステートレス検証

無状態検証を実現した後、RPCをサポートするノード（つまり、状態を保存するノード）は状態メルクルブランチを保存する必要がなくなります。これにより、ストレージの要求はさらに約50%削減されます。

4、新型ノード：部分的に状態を持たないノード

この革新的なアイデアは、L1ガス制限が10〜100倍に増加した後でも、個々のノードを稼働させ続けるための鍵となります。

新しいノードタイプを追加しました：無状態でブロックを検証し、無状態検証またはZK-EVMによってチェーン全体を検証しますが、一部の状態データのみを維持します。RPCリクエストに必要なデータがその状態のサブセット内にある限り、ノードは応答できます。他のリクエストは失敗するか（または外部のホスティングされた暗号解決策にロールバックする必要があります——ロールバックするかどうかはユーザーが選択します）。

! qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png

具体的に維持する状態はユーザーの設定によって異なります。例えば：

--既知のゴミ契約を除外したすべての状態。

--すべてのEOA、SCWアカウントおよび一般的なERC20/ERC721トークンとアプリケーションに関連する状態。

--ここ2年間にアクティブだったEOA/SCWアカウントの状態 + 一部の一般的に使用されるERC20トークンの状態 + 選ばれたスワップ/DeFi/プライバシーアプリの状態。

設定はオンチェーンコントラクトを通じて管理できます: ユーザーがノードを実行するときは、"--save_state_by_config 0x12345... 67890" パラメーターは、特定の言語でノードがリアルタイムで保存および更新する必要があるアドレス、ストレージ スロット、またはステータス フィルターのリストを定義します。 ユーザーは Merkle ブランチを保存する必要はなく、元の値のみを保存する必要があることに注意してください。

この種のノードは、重要な状態へのローカル直接アクセスの利点を提供するだけでなく、完全なアクセスのプライバシーを確保することができます。