Vitalik: ローカルノードに焦点を当てた拡張ロードマップの最適化計画

ネットワーク セキュリティに関する懸念の他に、L1 ガス制限の引き上げに対する最も一般的な批判は、フル ノードの実行がより困難になるという点です。特に、「フルノードのアンバインド」を中心としたロードマップの文脈では、この問題を解決するには、まずフルノードの重要性を理解する必要があります。

従来の見解では、フルノードはオンチェーン データを検証するために使用されます。これが唯一の問題であれば、ZK-EVM によって L1 スケーリングが解除されます。唯一の制限は、ブロック構築と証明コストを十分に低く抑えて、競争的な市場を可能にしながら 1/n の検閲耐性を維持することです。

しかし、現実にはこれが唯一の考慮事項ではありません。もう 1 つの重要な要素は、フルノードを実行すると、信頼性がなく、検閲に耐え、プライバシーを保護しながらオンチェーン データを読み取ることができるローカル RPC サーバーを利用できるようになることです。この記事では、この目標を達成するために現在の L1 拡張ロードマップを調整する方法について説明します。

1. ZK-EVM+PIR によって実現された分散化とプライバシーに満足できないのはなぜですか?

先月公開したプライバシー ロードマップでは、短期的には TEE + ORAM を使用し、長期的には PIR テクノロジに移行することを推奨しています。 Helios と ZK-EVM 検証を組み合わせることで、ユーザーは外部 RPC に接続する際に、(i) 取得されたチェーン データが正しいこと、(ii) データのプライバシーが保護されていることを確信できます。こうなると、疑問が湧いてきます。なぜそこで止まらないのか？これらの高度な暗号化スキームにより、自己ホスト型ノードは時代遅れになるのでしょうか?

これに対して私はいくつか回答があります:

--完全に信頼できない暗号化方式 (単一サーバー PIR など) は高価です。現在のコストは非現実的に高く、効率を複数回最適化した後でも高いままになる可能性があります。

--メタデータのプライバシーの問題。 IP アドレス自体のリクエスト時間やリクエストパターンなどのメタデータによって、多くのユーザー情報が公開されることになります。

--検閲の脆弱性: 少数の RPC プロバイダーが支配する市場構造では、ユーザーを禁止または検閲するという強い圧力に直面することになります。多くの RPC プロバイダーは、特定の国を完全にブロックし始めています。

したがって、個人ノードを実行する利便性を継続的に確保することは依然として価値があります。

2. 短期的な優先事項

EIP-4444 の完全展開を優先し、最終的には各ノードが約 36 日分のデータのみを保存するようにします。これにより、現在ノードの実行を妨げている最大の障壁であるハードディスク容量の要件が大幅に削減されます。その後、ノード ストレージ要件には、(i) 状態データ、(ii) 状態 Merkle ブランチ、および (iii) 36 日間の履歴データのみが含まれます。

各ノードが少量の期限切れの履歴データを保存するように、分散履歴ストレージ ソリューションを構築します。消失訂正符号化技術により信頼性を最大化します。これにより、中央集権的なサプライヤーに依存したり、ノードオペレーターに大きな負担をかけたりすることなく、「ブロックチェーンの永続的な保存」機能が保証されます。

ガス価格戦略を調整して、ストレージコストを増やし、実行コストを削減します。次の操作のガスコストの増加に重点を置きます: (i) 新しいストレージ スロットの SSTORE の実行、(ii) コントラクト コードの作成、(iii) ゼロ バランス/ゼロ ノンス アカウントへの ETH の転送。

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

ステートレス検証では、RPC をサポートするノード (つまり、状態を保存するノード) を実行する場合、状態 Merkle ブランチを保存する必要がありません。これにより、ストレージ要件をさらに約 50% 削減できます。

4. 新しいノード: 部分的にステートレスなノード

この革新的なコンセプトは、L1 ガス制限が 10 ～ 100 倍に増加した後も個人ノードを稼働させ続けるための鍵となります。

新しいノード タイプを追加しました。ステートレス方式でブロックを検証し、ステートレス検証または ZK-EVM を通じてチェーン全体を検証しますが、部分的な状態データのみを維持します。 RPC 要求に必要なデータがこの状態のサブセット内にある限り、ノードは応答できます。その他のリクエストは失敗します (または、外部でホストされている暗号化ソリューションにフォールバックする必要があります。フォールバックするかどうかはユーザーが選択できます)。

新しいノード タイプを追加しました。ステートレス方式でブロックを検証し、ステートレス検証または ZK-EVM を通じてチェーン全体を検証しますが、部分的な状態データのみを維持します。 RPC 要求に必要なデータがこの状態のサブセット内にある限り、ノードは応答できます。その他のリクエストは失敗します (または、外部でホストされている暗号化ソリューションにフォールバックする必要があります。フォールバックするかどうかはユーザーが選択できます)。

どの状態が維持されるかはユーザー設定によって異なります。例:

-- 既知のジャンク契約を除くすべての状態を除外します。

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

--過去 2 年間のアクティブな EOA/SCW アカウントのステータス + 一般的に使用されているいくつかの ERC20 トークンのステータス + 選択されたスワップ/DeFi/プライバシー アプリケーションのステータス。

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

このようなノードは、完全なアクセスのプライバシーを確​​保しながら、重要な状態へのローカルな直接アクセスという利点を提供します。