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

フルノードを運営することで、ローカルRPCサーバーを持つことができ、信頼不要、検閲耐性、プライバシーを保護した形でオンチェーンデータを読み取ることができます。

著者：ヴィタリック、イーサリアム創設者

翻訳：ゴールドファイナンス xiaozhou

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

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

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

1、なぜ ZK-EVM+PIR による非信任化とプライバシーに満足できないのか？

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

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

• 完全信頼のない暗号化スキーム（単一サーバーPIRなど）は高価です。現在のコストは現実的ではなく、何度も効率を最適化しても高い価格が維持される可能性があります。
• メタデータのプライバシー問題。IPアドレスのリクエスト時間、リクエストパターンなどのメタデータ自体が大量のユーザー情報を暴露する可能性があります。
• 脆弱性の審査：少数のRPCプロバイダーが主導する市場構造は、強力なユーザー禁止または審査の圧力に直面することになります。多くのRPCプロバイダーは、特定の国を完全にブロックし始めています。

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

2. 短期的な優先事項

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

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

Gas 価格戦略を調整し、ストレージコストを引き上げ、実行コストを下げます。特に以下の操作の Gas コストを引き上げます：(i) 新しいストレージスロット（storage slot）に対して SSTORE を実行すること、(ii) コントラクトコードを作成すること、(iii) ゼロ残高 / ゼロ nonce アカウントに ETH を送金すること。

3、中期目標：ステートレス検証

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

4. 新しいノード:一部のステートレスノード

この革新的な構想は、L1ガスの上限が10〜100倍に引き上げられた後でも、個人ノードの運用を維持するための鍵となるでしょう。

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

!

具体的に維持される状態はユーザーの設定に依存します。例えば：

• 既知のゴミ契約以外のすべての状態を除外する。
• EOA、SCW アカウントおよび一般的な ERC20/ERC721 トークンとアプリケーションに関連する状態。
• 過去2年間にアクティブなEOA/SCWアカウントの状態 + 一部の一般的なERC20トークンの状態 + 選ばれたスワップ/DeFi/プライバシーアプリの状態。

設定はオンチェーン契約で管理できます：ユーザーがノードを実行する際に「--save_state_by_config 0x12345...67890」パラメーターを使用します。このアドレスは特定の言語でノードが保存し、リアルタイムで更新する必要があるアドレスリスト、ストレージスロットまたは状態フィルタリングルールを定義します。ユーザーはマークルブランチを保存する必要はなく、元の値を保存するだけで済みます。

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