執筆：ヴィタリック、イーサリアム創設者編纂者:Golden Finance 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日分の履歴データ。 分散履歴ストレージ ソリューションは、各ノードが少量の期限切れの履歴データを格納できるように構築されています。 イレイジャーコーディング技術で信頼性を最大化します。 これにより、中央集権的なベンダーに頼ったり、ノードオペレーターに大きな負担をかけたりすることなく、「ブロックチェーン永遠」機能が保証されます。 ガス価格戦略を調整し、ストレージコストを引き上げ、実行コストを下げる。以下の操作のガスコストを重点的に引き上げる：(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トークンの状態 + 精選されたswap/DeFi/プライバシーアプリケーションの状態。 設定はオンチェーン契約によって管理されます：ユーザーがノードを実行する際に「--save\_state\_by\_config 0x12345...67890」パラメータを使用すると、そのアドレスは特定の言語でノードが保存し、リアルタイムで更新する必要があるアドレスリスト、ストレージスロット、または状態フィルタリングルールを定義します。ユーザーはマークルブランチを保存する必要はなく、元の値のみを保存すればよいことに注意してください。 この種のノードは、重要な状態へのローカルな直接アクセスの利点を提供するだけでなく、完全なアクセスのプライバシーを保証します。
Vitalik：ローカルノードに重点を置いたスケーラビリティロードマップの最適化案
執筆：ヴィタリック、イーサリアム創設者
編纂者:Golden Finance 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プロバイダーは、特定の国を完全に遮断し始めています。
したがって、個人ノードの運用の便利さを引き続き保障することには価値があります。
EIP-4444の全面的な展開を優先し、最終的に各ノードが約36日分のデータのみを保存することを実現します。これにより、ハードディスクの容量要求が大幅に削減され、現在ノードの運用を妨げている主要な障害が解消されます。その後、ノードの保存要求は次のもののみを含むことになります：(i)の状態データ、(ii)の状態マークルブランチ、(iii)36日分の履歴データ。
分散履歴ストレージ ソリューションは、各ノードが少量の期限切れの履歴データを格納できるように構築されています。 イレイジャーコーディング技術で信頼性を最大化します。 これにより、中央集権的なベンダーに頼ったり、ノードオペレーターに大きな負担をかけたりすることなく、「ブロックチェーン永遠」機能が保証されます。
ガス価格戦略を調整し、ストレージコストを引き上げ、実行コストを下げる。以下の操作のガスコストを重点的に引き上げる：(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トークンの状態 + 精選されたswap/DeFi/プライバシーアプリケーションの状態。
設定はオンチェーン契約によって管理されます：ユーザーがノードを実行する際に「--save_state_by_config 0x12345...67890」パラメータを使用すると、そのアドレスは特定の言語でノードが保存し、リアルタイムで更新する必要があるアドレスリスト、ストレージスロット、または状態フィルタリングルールを定義します。ユーザーはマークルブランチを保存する必要はなく、元の値のみを保存すればよいことに注意してください。
この種のノードは、重要な状態へのローカルな直接アクセスの利点を提供するだけでなく、完全なアクセスのプライバシーを保証します。