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

著者：Vitalik（イーサ創設者）; 翻訳：Golden Finance xiaozhou

L1ガスの上限引き上げに対する最も一般的な批判の一つは、ネットワークセキュリティへの懸念は別として、フルノードの運用が難しくなるというものだ。より難しくなる。特に「全ノードのアンバンドリング」を中心としたロードマップの文脈では、この問題に対処するには、全ノードが何を意味するのかを理解する必要がある。

従来の常識では、プレナムはオンチェーン・データを検証するために使用される。もしこれが唯一の問題であれば、ZK-EVMはL1スケーリングを解き放ちます。唯一の制限は、ブロックの構築と証明のコストを、両者が1/nの検閲耐性を維持し、なおかつ競争市場を形成できるほど低く保つことです。

しかし、現実的に考慮すべきことはこれだけではありません。もう1つの重要な要素は、フルノードを実行することで、信頼できる、検閲耐性があり、プライバシーを保護する方法でオンチェーンデータを読み取ることができるローカルRPCサーバーを持つことができるということです。この記事では、この目標を達成するために、現在のL1スケーリングロードマップをどのように適応させることができるかについて説明します。

1.なぜZK-EVM+PIRによって達成された非信頼性とプライバシーに満足しないのか？

先月発表された私のプライバシー・ロードマップでは、短期的にはTEEs+ORAMソリューションの採用を、長期的にはPIRテクノロジーへの移行を提唱しています。HeliosとZK-EVMの検証と組み合わせることで、外部RPCに接続するユーザーは、(i)取得したチェーンデータが正しいこと、(ii)データプライバシーが保護されていることを完全に確信することができます。ここで疑問が生じます。これらの高度な暗号化スキームは、セルフホストノードを時代遅れにするのでしょうか？

これにはいくつかの回答があります:

- 完全に信頼されない暗号化スキーム（たとえば、単一サーバーのPIR）はコストがかかります。現在のオーバーヘッドは非現実的なほど高く、多くの効率最適化を行っても高いままかもしれません。

-- メタデータプライバシーの問題。リクエスト時間、リクエストパターン、および IP アドレスの他のメタデータなどのメタデータは、本質的に多くのユーザー情報を公開します。

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

したがって、個々のノードの操作のしやすさを保護し続けることには、まだ価値があります。

2.短期的な優先事項

EIP-4444の完全な展開を優先し、最終的に各ノードに約36日分のデータしか保存させないという目標を達成する。約36日分のデータを保存する。これにより、現在ノードの稼働を妨げている最大の障害であるハードディスク・ドライブ容量の要件が劇的に削減されます。それ以降のノードのストレージ要件は、(i)状態データ、(ii)状態Merkleブランチ、(iii)36日間の履歴データのみとなります。

分散履歴ストレージスキームを構築し、各ノードが少量の古い履歴データを保存できるようにする。信頼性はコード修正技術によって最大化される。これにより、中央集権的なプロバイダーに頼ったり、ノードのオペレータに大きな負担をかけたりすることなく、「ブロックチェーンの不滅性」が保証される。

ガス価格戦略を調整し、ストレージのコストを高め、実行コストを下げる。(i)新しいストレージスロットのためにSSTOREを実行する、(ii)コントラクトコードを作成する、(iii)ETHをゼロバランス/ゼロノンスアカウントに送金する

3のGasコストを増加させることに焦点を当てます。中間目標：ステートレス認証

ステートレス認証の実装により、RPC対応ノードを実行しているノード（つまり、状態を保存しているノード）は、状態のMerkleブランチを保存する必要がなくなります。これにより、ストレージ要件をさらに50%削減できます。

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

この革新的なアイデアは、L1ガス上限が10～100倍に増加した後でも、個々のノードを実行し続ける鍵となります。キーとなります。

私たちは新しいノードタイプを追加しました：ステートレス検証またはZK-EVMでチェーン全体を検証しますが、ステートデータの一部のみを保持する、ステートレスなブロック検証方法です。ノードは、必要なデータがステートのサブセット内にある限り、RPCリクエストに応答することができます。その他のリクエストは失敗します（または、外部でホストされている暗号化ソリューションにフォールバックする必要があります。）

具体的にどの状態が維持されるかは、ユーザーの設定によって異なります。既知のジャンク契約以外のすべての状態を除外します。

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

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

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

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