ブロックアクセスリストはブロックパッカーがバリデーターに事前に伝えることができるようにします：「このブロックの取引は、これらのアカウントとストレージ位置にアクセスします」。この情報があると、バリデーターは事前に準備を整え、これらのデータをディスクからメモリにロードできます。その後、バリデーターは複数の取引を並行してチェックでき、1つずつではなく。工場の組み立てラインのようなものです：以前は1人の労働者が製品全体を担当していましたが、今では複数の労働者が同時に異なる部分を処理しています。

ePBS はブロックのパッキングと検証プロセスを分離する── ブロックビルダーが取引をパッキングし、提案者がブロックを提案し、バリデーターがブロックを検証します。各役割がはっきりしており、各々が自分の仕事をきちんと行うと、ブロックビルダーはより積極的により多くの取引をパッキングできます。提案者とバリデーターがチェックを手伝ってくれるので、セキュリティについて心配する必要はありません。

Gas フィーの再設定 + マルチディメンショナル Gas は、「コア戦略」と言えるかもしれません。現在、すべてのイーサリアムの操作には同じ Gas フィーが使用されています。しかし、Vitalik の考えでは、異なる操作には異なる価格があるべきです。

特に、新しい状態の作成（例：新しいアカウントの作成、新しい契約の展開）には特別な「状態作成料」が必要です。なぜなら、新しい状態を作成することは最も高価な操作だからです。それは計算リソースだけでなく、ストレージリソースも占有します。また、このコストは永続的です — 一度作成されると、その状態は永遠に存在します。

したがって、Vitalik の考え方は：新しい状態の作成をより高価にし、一般的な取引をより安価にすることです。

実現方法は「貯水池メカニズム」です。2 つのバケツがあると想像してください、1 つは「状態作成料」を含むバケツで、もう 1 つは「通常の Gas フィー」を含むバケツです。契約が互いに呼び出されると、Gas は自動的に 2 つのバケツから借りられ、混乱しないように保証されます。

一般ユーザーの取引はより安価になり、これらの取引には「状態作成料」を支払う必要がありません。一方、新しい状態を作成したい開発者は、より高い料金を支払う必要があります。これにより、ネットワーク全体の容量が急増しますが、状態の増加が制御され、フルノードのハードディスクが爆発することはありません。

長期的な展望は、メインネット自体を強化し、Layer 2 に依存しないことです。これには、Blobs + PeerDAS および ZK-EVM の段階的な展開が含まれます。

Blobs は、一時的な大容量ファイルストレージで、現在は主に Layer 2 に使用されています。将来的には、イーサリアムメインネット自体もデータを格納するために Blobs を使用します。しかし、問題も同様に発生します — 各ノードがすべての Blobs をダウンロードする必要があると、ネットワークは過負荷になります。

この場合、PeerDAS が必要になります — 全データをダウンロードする必要はなく、一部をダウンロードするだけで済みます。これは標本調査のようなもので、すべての人に尋ねる必要はなく、一部の人に尋ねるだけで全体の状況を推測できます。ZK プルーフと組み合わせることで、すべてのデータの 1/16 をダウンロードしていたとしても、データの完全性を確認できます。

次に ZK-EVM の段階的展開があります。これにより、ブロックの検証はもはやブロック内のすべてのトランザクションを再実行する必要がなくなり、ノードは ZK プルーフを信頼するだけで済み、検証コストは「すべてのトランザクションを実行する」から「1 つの ZK プルーフを検証する」に低下します。

Vitalik の計画では、2026 年に一部のノードが ZK 検証を試用します。2027 年までに、より多くのノードが使用するよう奨励されます。最終的に、有効なブロックには、5 つの異なるプルーフシステムからの 3 つのプルーフタイプが含まれている必要があります。彼は、すべてのノード（インデックスノードを除く）が最終的に ZK-EVM プルーフに依存すると予想しています。

「魔法の薬」のないスケーリング

さて、短期的および長期的なスケーリングでまだ議論されていない「ステートリソース」について見てみましょう。短期的には、引き続きブロックアクセスリストと同期し、p2p の改善、データベースの最適化などにより、約 5〜30 倍向上させることができますが、長期的にはどうなるでしょうか？

Vitalik の答えは、「ない」ということです。

なぜステートリソースを拡張するのが難しいのでしょうか？ Ethereum のステートは巨大なデータベースのようなものです。このデータベースには、すべてのアカウントの残高、すべてのスマートコントラクトのコード、すべてのストレージスロットのデータが格納されています。

現時点では、このデータベースはまだ大きく、約 100 GBしかありませんが、ステートを 20 倍に拡張した場合、2 TBになります。時間をもっとかけて考えるとどうなりますか？8 TB ですか？

問題はハードディスクに収まらないことではなく、次のような理由です：

- データベースの効率が低下します：現代のデータベースは、データを整理するためにツリー構造（例：Merkle ツリー）を使用しています。新しいデータを書き込む場合、ツリー全体を更新する必要があります。これはつまり、X 回の更新を行う場合、データベース操作も X 回になり、1 回の更新でデータベースを 1 回操作するだけでなくなります。更新が多くなるほど、操作も多くなり、書き込みが遅くなります。

- 同期が難しくなります：Ethereum ネットワークに新しく参加するノードは、新しいブロックを検証するために全体のステートをダウンロードする必要があります。データの規模が 8 TB に達すると、ほとんどの人の現在のインターネット速度では非常に長時間かかります。

解決策は存在しますが、Vitalik はそれらには問題があると考えています：

- 「ステートレス性の強化」：ノードは完全なステートを保存する必要はなく、ユーザーが Merkle プルーフを提供するだけで済みます。Vitalik によると、このアプローチにはステートストレージの中央集権化、動的なストレージアクセスがトランザクションの失敗を招き、帯域幅の問題があるということです。

- 「ステートの期限」：頻繁にアクセスされないステートは、アクティブなステートから自動的に削除されます。ノードは最近アクセスされたステートのみを保存すれば、ストレージ容量を大幅に削減できます。Vitalik によると、基本的な問題が存在し、「ステートが存在しない」ことを証明する方法があります。新しいステートを作成する場合、そのステートが「存在しなかった」ことをどのように証明するかが問題です。新しいアカウントを作成する場合、そのアカウントアドレスが過去に Ethereum 上に存在しなかったことを証明する必要があります。これは、すべての新しいアカウントを作成する際に、10 年間の履歴データをチェックする必要があることを意味し、新しいアカウントの作成が複雑でコストがかかることにつながります。

Vitalik の最終的なアプローチは、これら2つのアプローチを組み合わせ、いくつかの新しいステート形式を提案することで、Ethereum のステートリソースアーキテクチャ全体を変更するものです：

- 一時的なストレージ：自動的に期限切れになるストレージの形式。たとえば、新しい木を作成し、毎月リセットすることができます。この種のストレージは一時的なデータ、オーダーブック、流動性プール、一時的なカウンターなど、通常永続的な保存が不要なデータに使用することができます。1ヶ月後には古いオーダーが期限切れになり、新しい流動性プールが作成されます。

- 周期的なストレージ：一時的なストレージに類似しますが、より長いサイクル、たとえば1年です。

- 制限付きストレージ：特定の方法でのみアクセスできる一部のストレージ。たとえば、ERC20 トークンの残高ストレージは、特定のインタフェースを介してのみアクセス可能かもしれません。これにより、システムはこのようなストレージを最適化できます。

同時に、既存のステート形式は保持されます。これにより、実行コストを1000倍削減できます（ZK-EVMを介して）、しかし新しいステートの作成コストはたったの20倍削減される可能性があります。

Vitalik は、新しいステート形式があれば、開発者が選択肢を持つと考えています。既存のステート形式を引き続き使用し、より高い料金を支払うか、またはアプリケーションを再設計し、新しいステート形式を使用し、より低い料金を得るかを選択できます。一般的なユースケース（たとえば ERC20 残高、NFT）については、標準化されたワークフローが用意されていますが、より複雑なユースケース（DeFi など）については、開発者が最適化方法を考える必要があります。

この戦略は非常に興味深く、開発者によるコスト削減の知恵と、Ethereum ユーザー全体の利益が示唆されています。

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia