原文
The Anatomy of Ethereum’s State Access — weiihann (2026-06-29)
イーサリアムのステートアクセス解剖学
1. はじめに
すべてのイーサリアムトランザクションは、チェーンのステートの一部（アカウント残高、ナンス、コード、ストレージスロット）を読み書きします。チェーンが成長するにつれて、そのステートの大部分は長期間手つかずのままになります。そのため、休眠ステートとアクティブステートの分離、休眠ステートの有効期限設定、新しい形式のステートの作成など、ステート成長に対処するためのさまざまな方法がいくつかの提案で検討されています。このリサーチを最大限に支援するため、本レポートは以下の問いに答えることを目的としています。
- イーサリアムの歴史において、ステートアクセスと作成はどのように推移してきたか？
- 特定の期間にどれくらいのステートがアクセスされるか？
- 書き込みは主に作成、更新、削除のどれか？
- 読み込みは実際のデータをフェッチしているのか、それとも存在確認をしているだけなのか？
- アクティビティはどれくらい集中しているか？
- プロトコル内でのステート階層化スキームはどれくらい効果的か？
2. 要約
- 書き込みはステートの成長であり、変動ではない。 書き込まれたスロットの約55%は一度作成されると二度とアクセスされません。書き込みイベントの3分の2を占める更新は、繰り返しアクセスされる少数のホットセットに集中しています。
- 読み込みはほとんどが存在確認です。 個別のスロットごとに数えると、読み込み専用セットの83〜93%は存在しない値を返します。
- ステートアクセスは極めて集中しています。 2022年以降、読み込みアカウントの上位1%が読み込みアクセスの約96〜98%を占めており、ステーブルコイン、DEX、ブロックビルダーが主導しています。
- ウォームセットは実質的に書き込みセットです。 データが格納された読み込みを含めても、書き込みに加えて4〜9%しか増加しません。
- 書き込み経過時間（write-age）による階層化は、更新ガスを安価にカバーします。 スロット更新のSSTOREの94%（アカウントでは97%）は、30日間のウィンドウで既にウォームステートに存在するため、非アクティブステートのプレミアムは更新の3〜6%にしか影響しません。
- 約30日間のウィンドウが最適です。 ウォーム更新の約94%をカバーしつつ、ステートの約3%のみをアクティブステートに保ちます。ウィンドウを広げても、ウォームステートがはるかに増える割には、追加のカバー率はほとんど得られません。
3. データと手法
Tはウィンドウ長（日数）です。以下のウィンドウ化されたテーブルはすべてメインネットブロック24,870,000で終了し、§5.1と§6では、マージ後の履歴全体にわたって毎週リプレイされます。ウィンドウはT ∈ {1, 7, 14, 30, 60, 90, 180, 365}日です。オブジェクトタイプはアカウントとストレージスロットです。
すべてのソーステーブルはXatuから抽出されています。SQLクエリはこちらに含まれています。
| セット | テーブル |
|---|---|
| 書き込み（アカウント） | canonical_execution_balance_diffs, canonical_execution_nonce_diffs, canonical_execution_contracts |
| 書き込み（スロット） | canonical_execution_storage_diffs |
| 読み込み（スロット） | canonical_execution_storage_reads |
| 読み込み（アカウント、直接） | canonical_execution_balance_reads, canonical_execution_nonce_reads |
| 読み込み（アカウント、派生） | canonical_execution_address_appearances |
セットの定義
各(T, object_type)について：
- W: ウィンドウ内で作成、変更、または削除されたオブジェクト。
- R: ウィンドウ内で読み込まれただけで、書き込まれていないオブジェクト。
- R⁺: R内のオブジェクトのうち、読み込みがゼロ以外の（データが格納された）値を返すもの。
- R∪W = W + R: ウィンドウ内でアクセスされたすべてのオブジェクト。R⁺∪W = W + R⁺は、データが格納されたウォームセットであり、§5.1でウォームネスの指標として使用されます。
|W|はW内のオブジェクト数を表し、|R|も同様です。
実際には、書き込まれたすべてのオブジェクトは同じウィンドウ内で読み込まれます。スロットのSSTOREは読み込みに先行し、送信者のナンスはそれを書き込むトランザクションを検証するために読み込まれます。したがって、RはWを超えて何かを追加する明示的な読み込み（SLOADなど）のみをカウントします。
粒度と既知のギャップ
- システムコールステートは記録されません。 EIP-4788ビーコンルート、EIP-2935ブロックハッシュ履歴、EIP-7002/7251リクエストキューコントラクトへのブロックごとのプロトコル書き込みは表示されません。
- コンセンサス層の引き出しは記録されません。 バリデーターの引き出しは、EVM（イーサリアム仮想マシン）の書き込みなしで実行層のアドレスにクレジットされるため、引き出しのみの受取人はWから欠落しています。これは数万のアドレスであり、アカウント書き込みセットの1%をはるかに下回ります。
4. ステートアクセスと作成の様子
スロットまたはアカウントはさまざまな方法でアクセスされます。このセクションでは、ステートの書き込みと読み込みのパターンを探ります。
4.1 書き込み構造
ストレージの書き込みは3つのトランジションのいずれかであり、ほとんどの書き込まれたスロットは一度作成されると二度とアクセスされません。以下に2つの視点を示します。まず全期間のイベント合計、次にウィンドウ内で書き込まれたスロットがライフサイクルによってどのように分類されるかです。
チェーン履歴全体にわたる書き込みイベント
最初のステートアクティビティ（ブロック約46k、2015年7月）からブロック24,870,000までのすべての書き込みイベント。
スロット書き込みイベント（合計92.0億）：
| トランジション | イベント数 | 割合 |
|---|---|---|
| 更新 (x→y) | 6,109,404,842 | 66.4% |
| 作成 (0→x) | 2,323,710,153 | 25.3% |
| 削除 (x→0) | 765,554,231 | 8.3% |
アカウント書き込みイベント：
| ソース | メトリック | イベント数 | 割合 |
|---|---|---|---|
| 残高変更 (85.5億) | 調整 (x→y) | 7,965,568,085 | 93.1% |
| 資金提供 (0→x) | 385,657,967 | 4.5% | |
| 資金引き出し (x→0) | 203,518,204 | 2.4% | |
| ナンス変更 (34.2億) | 後続 | 3,043,409,094 | 89.0% |
| 初回使用 (0から) | 376,865,812 | 11.0% | |
| コントラクト作成 | 作成 | 100,078,703 | n/a |
2つの点が際立っています。
- 書き込みトラフィックは更新が支配的です。これまでのすべてのスロット書き込みイベントの66%以上が更新です。
- これまでに作成された全スロットの3分の1が削除されています。
書き込まれたスロットのライフサイクル
各書き込みイベントは3つのトランジションタイプのいずれかです（値はトランザクションごとの純額、§3）。
- C（作成）：
0 → x、空のスロットが設定される。 - U（更新）：
x → y、設定されたスロットの値が変更される。 - D（削除）：
x → 0、設定されたスロットがクリアされる。
その後、書き込まれたすべてのスロットは、ウィンドウ内でどのトランジションタイプを経験したかによって分類され、スロットはタイプを複数回経験する可能性があります。
- C: 一度作成され、その後アクセスされない。2回目の作成にはまず削除が必要なので、Cスロットは正確に1つの作成を持ちます。
- U: 1回以上更新され、作成も削除もされない。ウィンドウより前に存在し、その場で変更されたスロット。
- D: 一度削除され、作成も更新もされない。既存のスロットがクリアされた。
- C+U: 一度作成され、その後1回以上更新され、削除されない。削除がないため、正確に1つの作成を持ち、
+Uは1回の更新または多数の更新をカバーします。 - C+D: 作成され、削除されたが更新されず、1回以上の生成と消滅のサイクル。
- U+D: 1回以上更新され、その後削除された。ウィンドウより前に存在した。
- C+U+D: 作成され、1回以上更新され、削除された、完全なライフサイクル。
以下の表は、マージ後のスイープ全体で平均化された構成を示しており、各週ごとのアンカーは等しく重み付けされています。
| T (日数) | C | C+U | U | C+U+D | C+D | U+D | D |
|---|---|---|---|---|---|---|---|
| 30 | 53.3% | 8.2% | 14.4% | 2.8% | 12.1% | 0.8% | 8.4% |
| 90 | 54.9% | 9.2% | 11.4% | 3.3% | 12.9% | 0.7% | 7.7% |
| 180 | 55.5% | 10.0% | 9.4% | 3.7% | 13.6% | 0.6% | 7.2% |
| 365 | 55.4% | 11.4% | 7.0% | 4.2% | 14.7% | 0.5% | 6.8% |
作成はすべてのウィンドウで支配的であり、|W|の約55%を占めます。 ほとんどのスロットはウィンドウ内で初期化され、その後二度とアクセスされません。これは変動ではなくステートの成長です。Cは最も変動の激しいクラスでもあります。T=30では、週ごとに38%から68%の間で変動し、2024年のアクティビティ急増期には低下し、その後回復しています。
C+Dは最大の混合クラスであり、|W|の約12〜15%を占めます。 これらはウィンドウ内で生成され消滅する一時的なスロットです。この割合は、タイムライン上のどのウィンドウでも安定しています。
作成はより長いウィンドウでさらに支配的になります。 作成を含むクラス（C、C+U、C+D、C+U+D）は、T=30で|W|の約76%、T=365で約86%を占める一方、純粋なインプレース更新（U）は14%から7%に半減します。ウィンドウが長くなると、各スロットの生成がより多く捕捉されるため、書き込みセットはさらに成長主導に見えます。
4.2 読み込み構造
読み込みはゼロまたはゼロ以外の2つの異なる戻り値を持つことができます。書き込みと同様に、全期間の合計と、時間経過に伴うウィンドウごとの分割という2つの視点を示します。
チェーン履歴全体にわたる読み込みイベント
全履歴にわたるすべての読み込みイベント。
スロット読み込みイベント（合計236.9億、書き込みイベントの2.6倍）：
| 戻り値 | イベント数 | 割合 |
|---|---|---|
| ゼロ以外 | 16,552,716,483 | 69.9% |
| ゼロ | 7,138,221,664 | 30.1% |
アカウント読み込みイベント：
| ソース | メトリック | イベント数 | 割合 |
|---|---|---|---|
| 残高読み込み (151.0億) | ゼロ以外 | 9,845,422,896 | 65.2% |
| ゼロ | 5,251,717,095 | 34.8% | |
| ナンス読み込み (136.4億) | ゼロ以外 (インクリメント後、0になることはない) | 13,637,765,012 | 100% |
| 出現 (419.8億) | 内部呼び出しターゲット / 呼び出し元 | 各157.4億 | 各37.5% |
| トランザクション送信者 / 手数料受取人 / トランザクション受取人 | 各33.9億 | 各8.1% | |
| コントラクト作成者 / 新規コントラクト | 各約1億 | 各0.24% | |
| selfdestruct呼び出し元 / 返金受取人 | 各約6000万 | 各0.14% |
手数料受取人は、トランザクションの優先手数料がクレジットされるブロックプロポーザーであり、コンセンサス層の引き出しではありません（それらは記録されません）。
示されているように、ほとんどの読み込みイベントはアカウントとスロットの両方でゼロ以外です。これらの読み込み合計には、書き込みに結合された読み込みが含まれます。なぜなら、すべての書き込みには読み込みが先行するからです（SSTOREごとに1つのSLOAD）。書き込みに結合された読み込みは書き込み数と正確に等しいため、スロットの場合、それらは全読み込みイベントの約35%であり、約65%が書き込みセットを超える真の読み込みとして残ります。
読み込みが返すもの
R内の各読み込みはzero（空スロットのプローブ、「このスロットは設定されているか？」）またはnonzero（データが格納されている）を返します。Rには、ウィンドウ内で読み込まれただけで、書き込まれていないオブジェクトのみが含まれます。|R|の割合として、マージ後の週ごとのスイープで平均化された値です。
| T (日数) | ゼロのみ | ゼロ以外のみ |
|---|---|---|
| 30 | 82.5% | 17.5% |
| 90 | 87.1% | 12.8% |
| 180 | 89.8% | 10.1% |
| 365 | 92.6% | 7.4% |
Rのほとんどは空スロットのプローブです。 Rの約7〜18%のみが実際にデータが格納された読み込みであり、その割合はウィンドウが広がるにつれて縮小します。
これは、上記の全履歴テーブルの69.9%のゼロ以外と矛盾しません。これらは異なるものをカウントしています。69.9%はイベントごとの割合です。これまでのすべてのSLOADのうち、約70%はデータが格納されたスロットにヒットしています。これは、少数のホットなデータが格納されたスロットが繰り返し読み込まれるためです。ここでの約7〜18%は、読み込み専用セットR内の個別のスロットごとの割合です。ウィンドウ内で読み込まれるだけのほとんどのスロットは、1回限りの存在確認プローブであり、それぞれ1回ヒットします。読み込みイベントで重み付けすると、データが格納された読み込みが支配的です。オブジェクトで重み付けすると、空のプローブがより大きな割合を占めます。
5. ウォームネスと集中度
このセクションでは、ステートのどれくらいが「ウォーム」（ウィンドウ内でアクセスされた）であるか、およびオブジェクト全体でアクセスがどれくらい集中しているかを調べます。
5.1 ウォームネス：どれくらいのステートがアクティブか
各値は、マージ後の週ごとのスイープにおける平均値であり、ウィンドウごとに1つです。読み込み専用列はR⁺であり、ゼロ以外の（データが格納された）値を返す読み込みのみをカウントするため、空スロットのプローブはウォームセットから除外されます。
スロット（ライブスロットの平均割合）：
| T (日数) | W | R⁺ | R⁺∪W |
|---|---|---|---|
| 30 | 2.82% | 0.21% | 3.03% |
| 90 | 7.55% | 0.39% | 7.95% |
| 180 | 13.60% | 0.55% | 14.15% |
| 365 | 24.17% | 0.70% | 24.88% |
アカウント（ライブアカウントの平均割合）：
| T (日数) | W | R⁺ | R⁺∪W |
|---|---|---|---|
| 30 | 3.30% | 0.46% | 3.76% |
| 90 | 7.94% | 1.07% | 9.01% |
| 180 | 13.45% | 1.79% | 15.24% |
| 365 | 23.08% | 2.51% | 25.59% |
結合（総ステートに対するスロットとアカウントの平均割合）：
| T (日数) | W | R⁺ | R⁺∪W |
|---|---|---|---|
| 30 | 2.91% | 0.26% | 3.16% |
| 90 | 7.63% | 0.51% | 8.14% |
| 180 | 13.58% | 0.77% | 14.36% |
| 365 | 23.99% | 1.04% | 25.03% |
ウォームセットは、ウィンドウが長くなるほどより多くのステートを捕捉するため、すべてのウィンドウでTとともに成長します。データが格納された読み込みセットは、全体を通して書き込みセットのごく一部に留まります。
時間経過に伴うウォームネス
以下のパネルは、スロット、アカウント、および結合されたセットが、それぞれのライブステートの分母に対する割合として示されています。
書き込みセットのグラフでは、スロットの割合はマージ後のタイムライン全体で下降傾向にあります（ライブステートがウィンドウ内の書き込みセットよりも速く成長するため）。一方、アカウントの割合はより安定しています。両方とも2025年後半から上昇します。データが格納された読み込みセットR⁺は、どのウィンドウでも小さく、徐々に成長しており、スロット側よりもアカウント側でより顕著です。
5.2 集中度
各アクセスセットとウィンドウについて、上位1%のオブジェクトによって捕捉されるアクセスの割合。アクセスは(トランザクション、オブジェクト)イベントごとです（§3）。
スロット、上位1%のアクセス割合：
| T (日数) | W | R | R∪W |
|---|---|---|---|
| 1 | 48.0% | 65.7% | 56.4% |
| 30 | 62.3% | 83.8% | 72.3% |
| 90 | 66.1% | 87.1% | 76.1% |
| 365 | 68.2% | 87.7% | 77.9% |
アカウント、上位1%のアクセス割合：
| T (日数) | W | R | R∪W |
|---|---|---|---|
| 1 | 40.8% | 78.9% | 57.5% |
| 30 | 60.5% | 96.0% | 77.7% |
| 90 | 64.0% | 98.0% | 82.0% |
| 365 | 69.0% | 98.7% | 86.4% |
RはどこでもWよりも集中しています。 T=365dでは、Rスロットの上位1%がスロット読み込みアクセスの約88%を占め、Rアカウントの上位1%が約98%を占めます。ごく少数の人気コントラクトがほとんどすべての読み込み操作を吸収しています。
集中度はTとともに増加します。 ウィンドウが広くなると、アクセス頻度の低いテールキーが取り込まれるため、ヘッドの相対的な重みが増加します。T=1dからT=30dへの増加が最も急激で（スロットRで約18パーセンテージポイント、アカウントRで約17パーセンテージポイント）、その後は横ばいになります。
アカウントはスロットよりもはるかに密接に集中しています。 T=30dでは、Rアカウントの上位1%がアクセスの96%を捕捉するのに対し、スロットでは84%です。アカウントの読み込みはごく少数の人気コントラクトに集中しますが、スロットの読み込みは多くのコントラクトのストレージに分散します。
時間経過に伴う集中度
アカウント読み込みの集中度は極端であり、サンプル全体でその状態が続いています。最新のアンカー（ブロック24,870,000）では、Rアカウントの上位1%が読み込みアクセスの**96〜98%**を占めており、より広いウィンドウでは2022〜2023年には既にその水準に達していました（T=90で約93%、T=180で約95%、T=365で約97%）。変動があった唯一のウィンドウは短い30日間のウィンドウで、読み込みトラフィックがごく少数の頻繁に呼び出されるコントラクトに統合されるにつれて、約87%から約96%に上昇しました。スロットの集中度は低く、より緩やかに上昇しました（T=365で約78%から約88%）。
トップにいるのは誰か
T=365dウィンドウ（ブロック24,870,000）で最もアクセスされた（RuW）アカウント上位10件（全ソースからのアクセス数順）：
| 順位 | アカウント | アクセス数 | 内容 |
|---|---|---|---|
| 1 | 0x4838b106fce9647bdf1e7877bf73ce8b0bad5f97 | 11.9億 | Titan Builder |
| 2 | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 | 7.29億 | USDC |
| 3 | 0xdadb0d80178819f2319190d340ce9a924f783711 | 7.29億 | BuilderNet |
| 4 | 0xdac17f958d2ee523a2206206994597c13d831ec7 | 6.15億 | USDT |
| 5 | 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 | 5.79億 | WETH |
| 6 | 0x43506849d7c04f9138d1a2050bbf3a0c054402dd | 4.28億 | 不明 |
| 7 | 0x396343362be2a4da1ce0c1c210945346fb82aa49 | 2.41億 | QuasarBuilder |
| 8 | 0x000000000004444c5dc75cb358380d2e3de08a90 | 2.17億 | Uniswap V4 PoolManager |
| 9 | 0x609e0f0cb16e53878ba5e959a22fc7fcd81b124a | 2.09億 | 不明 |
| 10 | 0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5 | 2.05億 | beaverbuild |
上位は2つに分かれます。ブロックビルダー（Titan、BuilderNet、QuasarBuilder、beaverbuild）は、マージ後、すべてのトランザクションがブロックの手数料受取人にクレジットされるため、リストのトップに立っています。これは、ビルダーが構築するすべてのブロックのすべてのトランザクションで手数料受取人であるためです。コントラクトは、実際に頻繁にアクセスされるアカウントです。ステーブルコイン（USDC、USDT）、WETH、そしてUniswap V4シングルトンです。
したがって、アカウント集中度のトップは、手数料のクレジットによって引き上げられた少数の支配的なビルダーと、ほとんどの呼び出しトラフィックを吸収するごく少数のコントラクトが混在しています。
同じウィンドウでストレージスロットが最もアクセスされたコントラクト上位10件：
| 順位 | コントラクト | スロットアクセス数 | 内容 |
|---|---|---|---|
| 1 | 0xdac17f958d2ee523a2206206994597c13d831ec7 | 13.1億 | USDT |
| 2 | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 | 7.99億 | USDC |
| 3 | 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 | 3.32億 | WETH |
| 4 | 0x06450dee7fd2fb8e39061434babcfc05599a6fb8 | 3.17億 | XEN |
| 5 | 0x000000000004444c5dc75cb358380d2e3de08a90 | 1.33億 | Uniswap V4 PoolManager |
| 6 | 0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b | 5400万 | Uniswap V3 USDC/USDT pool |
| 7 | 0x2b591e99afe9f32eaa6214f7b7629768c40eeb39 | 5200万 | HEX |
| 8 | 0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb | 5100万 | Morpho |
| 9 | 0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2 | 4500万 | Aave V3 Pool |
| 10 | 0xe0554a476a092703abdb3ef35c80e0d76d32939f | 4400万 | Uniswap V3 USDC/ETH pool |
トークン残高とアローアンスマッピング（USDT、USDC、WETH）、DEX（Uniswap V4シングルトンと2つの活発なUniswap V3プール）、レンディング（Aave V3、Morpho）、そして高頻度でミント/ステークされるトークン（XEN、HEX）です。これらは、他のどのコントラクトよりもストレージが頻繁に読み書きされるコントラクトです。
6. EIP-8295：ステート階層化の反実仮想
これまでのセクションでは、イーサリアムの歴史におけるステートアクセスと作成の様子を説明しました。このセクションでは、ステート階層化スキームの有効性を探ります。
EIP-8188は、すべての口座とストレージスロットに[[glossary/lastwrittenblock|最終書き込みブロック]]フィールドを追加し、各ステートが最後に変更された時期を記録するコンセンサスレベルのメタデータとします。これ自体はガス料金を変更しません。EIP-8295は、そのメタデータに基づいて構築された階層化スキームです。最近書き込まれたステートを安価に（アクティブステート）、長期間休眠しているステートをより高価に（非アクティブステート）価格設定し、そのアクティブネスの閾値をローリングT日間のウィンドウとして扱います。以下のセクションでは、その層を反実仮想としてモデル化します。「アクティブ」と「非アクティブ」はこれを指します。
6.1 ウォーム更新のカバー率
定義
各ウィンドウについて、すべての更新イベントをウォームまたはコールドに分類します。
- ウォーム: オブジェクトが同じウィンドウ内で既に作成または更新されている。
- コールド: その更新が、ウィンドウ内でオブジェクトの最初のウォーム化イベントである。削除はウォーム化とはみなされない。
したがって、オブジェクトのウィンドウ内での最初の作成または更新はコールドである可能性があり、その後のすべての更新はウォームです。
カバー率
各値は、マージ後の週ごとのスイープにおけるウォーム更新イベントの平均割合です。
| T (日数) | スロットのウォーム率 | アカウントのウォーム率 |
|---|---|---|
| 1 | 85.2% | 92.0% |
| 7 | 91.2% | 95.1% |
| 30 | 94.1% | 97.0% |
| 90 | 95.7% | 98.0% |
| 180 | 96.7% | 98.6% |
| 365 | 97.7% | 99.0% |
アクティブステート層は更新ガスを十分にカバーします。 T=30dではスロット更新のSSTOREの約94%が安価なアクティブ価格を維持し、T=90dでは約96%が維持されるため、非アクティブステートのプレミアムはスロット更新の約3〜6%にしか影響しません。1日間のウィンドウでも、スロット更新ガスの85%、アカウント更新ガスの92%を既にカバーしています。
スロットは、低い方ではアカウントよりもウィンドウに敏感です。 ウィンドウを30dから1dに短縮すると、スロットのカバー率は94%から85%に低下しますが、アカウントのカバー率は97%から92%にしか低下しません。アカウントステート（ホットコントラクト）は短いウィンドウ内で何度も書き換えられるため、ほとんどすべてのアカウント更新には既に同日以前の書き込みがあります。
メリットはすぐに飽和します。 スロットのカバー率はT=30dで約94%からT=365dで約98%に上昇しますが、これは12倍のウィンドウでわずか+4ppの増加に過ぎません。アカウントはさらに横ばいです（約97%から約99%）。約30日を超えて延長しても、更新ガスにはほとんど影響がありません。
約30日間のウィンドウが最適です。 T=30dからT=365dに移行しても、スロットのカバー率はわずか+3.6pp（94.1%から97.7%）しか増加しませんが、ウォームに保つ必要があるアクティブステートセットは**ライブスロットの2.8%から24.2%**に増加します（§5.1）。これは、ほとんど追加のガスをカバーすることなく、安価な層に約9倍ものステートを保持することになります。約30日間の閾値は、ウォーム更新ガスのほぼすべてを捕捉しつつ、アクティブステートセットを小さく保ちます。これは階層化スキームが望むものです。
6.2 読み込み側期間のバンプ
非アクティブなオブジェクトの最初の読み込みもその期間をバンプし、読み込みをユーザーにとって書き込みのように扱うという仮説的な拡張の下で、どのオブジェクトがそのコストを支払うでしょうか？
UXの悪いセットとは、ウィンドウ内の最初のイベントがゼロ以外の読み込みであるオブジェクトです。例えば、最初のイベントがデータが格納されたSLOADであるスロット、または最初のイベントがゼロ以外の残高またはナンス読み込みであるアカウントなどです。最初のイベントが書き込みまたはゼロ読み込みである場合は、書き込みが既にメタデータを更新し、ゼロ読み込みはメタデータを格納しないため、コストはかかりません。
EIP-8188は、書き込み経過時間（write-age）を書き込み時のみ更新し、読み込み時には更新しません。読み込み時に期間をバンプするスキームは書き込みと同じくらいのコストがかかるため、その影響を評価したいと考えます。
スロット：最初の操作の分類
R∪W内のスロットのうち、最初のイベントが何であるかによる割合：
| T (日数) | 最初の操作 = 書き込み | 最初の操作 = ゼロ読み込み | 最初の操作 = ゼロ以外の読み込み |
|---|---|---|---|
| 30 | 67.90% | 26.32% | 5.77% |
| 90 | 69.34% | 26.57% | 4.09% |
| 180 | 69.86% | 26.93% | 3.21% |
| 365 | 70.28% | 27.37% | 2.35% |
T=30dでは、R∪W内のスロットの**5.8%が読み込み側のバンプの影響を受け、その最初のイベントはデータが格納されたSLOADとなります。これはT=365dでは2.4%**に低下します。なぜなら、ウィンドウが広くなると、より早い書き込みが含まれる可能性が高くなるためです。
アカウント：最初の操作の分類
R∪W内のアカウントのうち、最初のイベントが何であるかによる割合：
| T (日数) | 最初の操作 = 書き込み | 最初の操作 = ゼロ読み込み | 最初の操作 = ゼロ以外の読み込み |
|---|---|---|---|
| 30 | 89.65% | 0.91% | 9.44% |
| 90 | 89.67% | 1.04% | 9.29% |
| 180 | 89.96% | 1.14% | 8.89% |
| 365 | 90.91% | 1.19% | 7.90% |
UXの悪いセットは、T=30dでウォームアカウントの約9%を占め、T=365dでは約8%に緩和されます。ゼロ読み込みの帯域は全体を通して小さく（約1%）維持されます。
タイムライン全体を通して、UXの悪いセットは少数派に留まり、データが格納されたアカウントで読み込み専用セットが満たされるにつれて緩やかに増加し、2023年初頭と2025年には短期間で約20%に達する変動がありました。
結論
イーサリアムのステートは、変動するよりもはるかに速く成長します。ほとんどの書き込みは新しいステートを作成し、その後二度とアクセスされず、任意の固定ウィンドウでアクティブなステートの割合はチェーンが古くなるにつれて減少し続けます。その結果、すべてのステートフルノードが永遠に保持する大量の休眠ステートが生じ、実際の活動は少数のアプリケーションが主導する小さなホットセットに集中しています。
これはまさに、アクティブステートと休眠ステートを分離する価値があることを示す形です。書き込み経過時間（write-age）による階層化は、ガス関連の書き込み活動のほぼすべてを小さなアクティブステートセットに配置します。30日間のウィンドウで既に更新ガスの約94%をカバーしつつ、ステートの約3%のみをウォームに保ち、残りを非アクティブステートとマークします。休眠テールはチェーンとともに成長するため、それを異なる方法で扱う価値は時間とともに複利的に増加します。
階層化はそのアイデアの一つの表現です。同じ構造がステート有効期限、部分ステートレス性、およびすべてのステートを等しくライブとして扱うことをやめるあらゆる設計の基盤となっています。アクティブセットは小さく限定されているため、イーサリアムはこの非対称性に基づいてステートを継続的にスケーリングすべきです。
1投稿 - 1参加者