この記事はイーサリアム共同創設者Vitalikによるものです
編集者 | Odaily Planet Daily ( @OdailyChina )
翻訳者 |イーサン（ @ethanzhang_web3 ）
ネットワーク セキュリティに関する懸念は別として、L1 ガス制限の引き上げに対する最も一般的な批判は、フル ノードの実行がより困難になるというものです。特に、フルノード分割に焦点を当てたロードマップの文脈では、この問題に対処するにはフルノードの役割を理解する必要があります。
歴史的に、フルノードはオンチェーン データを検証するものと考えられてきました。一般ユーザーが検証できない場合に何が起こるかについての私の見解については、 こちらをご覧ください。それが唯一の問題であれば、ZK-EVM は L1 スケーリングのロックを解除します。唯一の制限は、ブロック構築と証明コストを十分に低く抑えて、 1/n検閲耐性と市場競争力を維持することです。
しかし、実際には、問題はこれだけではありません。もう 1 つの大きな問題は、信頼性がなく、検閲に耐え、プライバシーに配慮した方法でチェーンを読み取るために使用できるローカル RPC サーバーを持つことができるように、フル ノードを持つことが極めて重要であることです。このドキュメントでは、この目標を達成するための現在の L1 スケーリング ロードマップの調整について説明します。
ZK-EVM + PIR を通じて信頼性とプライバシーを実現し続けるのはなぜですか?
先月公開したプライバシー ロードマップには、短期的な解決策として TEE + ORAMが、長期的な解決策としてPIRが含まれていました。これを Helios および ZK-EVM 検証と組み合わせることで、すべてのユーザーは次の点に完全に自信を持って外部 RPC に接続できます。(i) 取得するチェーンは正しいものであること。 （ii）データのプライバシーが保護される。だから私たちはこう問わずにはいられません。なぜここで止まることができないのか？これらの高度な暗号化ソリューションにより、セルフホスト型ノードは時代遅れの遺物になってしまうのではないでしょうか?
ここで、いくつかの答えを挙げることができます。
完全に信頼できない暗号化ソリューション (つまり、1 サーバーの PIR) は非常に高価になります。現在のコストは非現実的なほど高く、多くの効率改善を行った後でも高額なままになる可能性があります。
メタデータのプライバシー。どの IP アドレスがいつリクエストを行ったか、またリクエストのパターンから、ユーザーに関する多くの情報を明らかにすることができます。
検閲の脆弱性: 少数の RPC プロバイダーが支配する市場構造では、ユーザーのプラットフォームを削除したり検閲したりする強い圧力に直面することになります。多くの RPC プロバイダーは国全体を除外しています。
これらの理由から、個人用ノードの実行がより簡単になるように継続的に取り組むことには価値があります。
短期的な優先事項
各ノードが約 36 日分のデータのみを保存する最終状態になるまで、EIP-4444 の完全展開を優先します。これにより、ディスク スペースの要件が大幅に削減されます。これは、より多くの人がノードを実行できない主な原因です。その後、ノードのディスク容量要件は次のようになります: (i) 状態サイズ。 (ii) 州マークル支店（iii）36日間の履歴。
各ノードが期限よりも古い履歴データの小さな部分を保存できる分散履歴ストレージ ソリューションを構築します。消失訂正符号を使用して堅牢性を最大限に高めます。これにより、中央集権的なプロバイダーに依存したり、ノードオペレーターに大きな負担をかけたりすることなく、ブロックチェーンが不変であることが保証されます。
ガス価格を調整して、ストレージを高価にし、実行を安価にします。特に優先されるのは、新しい状態を作成するためのガスコストの増加です: (i) 新しいストレージスロットの SSTORE、(ii) コントラクトコードの作成、(iii) まだ残高や nonce がないアカウントへの ETH の送信。
中期優先事項: ステートレス認証
ステートレス検証を有効にすると、状態 Merkle ブランチを保存せずに RPC 対応ノード (つまり、状態を保存するノード) を実行できるようになります。これにより、ストレージ要件がさらに約 2 倍削減されます。
新しいタイプのノード: 部分的にステートレスなノード
これは新しいアイデアであり、L1 ガス制限が 10 ～ 100 倍に増加したときに個々のノードを実行できるようにするための鍵となります。
ブロックをステートレスに検証し、チェーン全体を検証し (ステートレス検証または ZK-EVM 経由)、状態の一部を最新の状態に維持できるノード タイプを追加しました。必要なデータがこの状態のサブセット内にある限り、ノードは RPC 要求に応答できます。その他のリクエストは失敗します (または、外部でホストされている暗号化ソリューションにフォールバックする必要があります。これを行うかどうかはユーザーが選択できます)。
保持される状態の正確な部分は、ユーザーが選択した構成によって異なります。以下に例をいくつか挙げます。
既知のジャンク契約を除くすべての州
すべてのEOAとSCW、および一般的に使用されるすべてのERC 20およびERC 721トークンとアプリケーションに関連するステータス
過去2年間にアクセスされたすべてのEOAとSCW、いくつかの一般的に使用されているERC 20トークン、および一部の取引所、Defi、プライバシーアプリケーションに関連付けられたステータス
構成はオンチェーン コントラクトを介して管理できます。ユーザーは--save_state_by_config 0x 12345...67890を使用してノードを実行できます。これにより、ノードが保存して最新の状態に保つアドレス、ストレージ スロット、またはその他のフィルター処理された領域のリストが何らかの言語で指定されます。ユーザーは Merkle ブランチを保存する必要がないことに注意してください。元の値を保存するだけで済みます。
このタイプのノードにより、ユーザーは関心のある状態にローカルで直接アクセスでき、その状態へのアクセスのプライバシーが最大限に高まります。
