[EIP7973] 同じアドレスへの2回目以降のETH送金を安くする仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、同一トランザクション内でアカウントのフィールド（nonce、残高、コードハッシュ）を2回以上更新する時、2回目以降のガスコストを引き下げる仕組みを導入するEIP7973についてまとめていきます！

以下にまとめられているものを解説しながらまとめていきます。

EIP-7973: Warm Account Write MeteringIntroduce warm account writes, decreasing the cost of writing to an account after the first write.Ethereum Improvement Proposals

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

EIP7973とは、アカウントへの書き込み操作に「2回目以降は安くする」仕組み（warm metering）を導入する提案です。アカウントのフィールド（nonce、value（残高）、codehash）がトランザクション内で2回以上変更される場合、2回目以降の書き込みコストを削減します。

Warm Metering（ウォームミータリング）とは

最初のアクセス（コールドアクセス）と2回目以降のアクセス（ウォームアクセス）でガスコストを変える仕組みです。ストレージの読み書きではEIP2929で既に導入されていますが、アカウントフィールドの書き込みにはまだ適用されていません。

ステートルート（Ethereumの全状態を表すハッシュツリーの根）の更新はブロック構築で最もコストが高い処理の一つですが、同じアカウントへの複数回の更新はバッチ処理できるため、2回目以降の実際のコストは1回目より低くなります。 EIP7973はこの実態に合わせてガスコストを調整します。

動機

ETH送金とWETH送金のコスト不公平

現在のEthereumでは、ストレージへの書き込みにはEIP2200で導入されたネット計量（net metering）が適用されています。同じストレージスロットへの複数回の書き込みは、最初のコールドアクセスコストが償却され、2回目以降は安くなります。

EIP2200については以下の記事を参考にしてください。

スマートコントラクトの脆弱性を理解してBugハンターになろう

しかし、アカウントフィールドの更新にはこのような割引がありません。例えば、1つのトランザクション内でETHを複数のアドレスに送金する場合を考えます。

WETH（Wrapped ETH）を使ったTransferはストレージの書き込みなので「2回目以降は安くなる」恩恵を受けます。一方、ネイティブETHのTransferはアカウントのbalanceフィールドの更新であり、毎回同じコストが課金されます。同じ送金先に何度送っても割引がないのです。

この不公平は、開発者がネイティブETHの使用を避けてWETHを選ぶ動機になっており、将来のPAYやGAS2ETHのような値Transferを含む新しいオペコードにも不利に働きます。

ステートルート更新のコスト実態

Ethereumのアカウントは(nonce, balance, storage_root, codehash)の4つのフィールドからなるタプルで、Merkle Patricia Tree（MPT）のリーフとして保存されています。アカウントの任意のフィールドを変更するとMPTのステートルート再計算が必要ですが、同じアカウントへの複数回の変更はバッチ処理できます。つまり、2回目以降のステートルート再計算は不要であり、実際のコストは低いのです。

この提案による解決策

EIP7973はアカウント書き込みにコールド/ウォームの区別を導入します。トランザクション内で初めてアカウントを更新する時は「コールドライト」（高コスト）、既に更新済みのアカウントへの追加更新は「ウォームライト」（低コスト）として課金されます。これにより、ETH送金のコストが実態に合ったものになり、WETHとの不公平が解消されます。

仕様

パラメータ定義

EIP7973では、既存のGAS_CALL_VALUEとGAS_STORAGE_UPDATEパラメータを廃止し、以下の3つのパラメータを導入します。

パラメータ	値	説明
`GAS_COLD_STORAGE_WRITE`	未確定	ストレージトライへの1回の更新コスト。
`GAS_COLD_ACCOUNT_WRITE`	未確定	アカウントトライへの1回の更新コスト（初回更新時に課金）。
`GAS_WARM_WRITE`	未確定	ウォーム状態のトライへの書き込みコスト（ステートルート再計算不要）。

パラメータ値は未確定

具体的なガスコスト値は、ステートフルベンチマークの結果に基づいて決定される予定です。ベンチマークは現在開発中です。

アカウント更新オペコードのガスコスト変更

CREATE、CREATE2、*CALL（CALL、STATICCALL等）のようなアカウントを更新するオペコードでは、以下のようにコストが決まります。

flowchart TD
    A[アカウント更新オペコード実行] --> B{"アカウントのフィールドは\nトランザクション開始時と同じ?"}
    B -- はい（初回更新） --> C["GAS_COLD_ACCOUNT_WRITE\nを課金（高コスト）"]
    B -- いいえ（既に更新済み） --> D["GAS_WARM_WRITE\nを課金（低コスト）"]

判定基準は「アカウントのフィールドがトランザクション開始時の値と等しいかどうか」です。等しい場合はまだ更新されていないことを意味するためコールドライトとなり、等しくない場合は既に更新済みのためウォームライトとなります。

以下の図は、同一アドレスに複数回ETHを送金する場合の現行方式とEIP7973のコスト比較です。

例えば、あるアドレスにETHを2回送金する場合、1回目の送金ではbalanceフィールドが初めて変更されるためGAS_COLD_ACCOUNT_WRITEが課金されます。 2回目の送金ではbalanceは既にトランザクション開始時と異なっているため、GAS_WARM_WRITEのみが課金されます。

`SSTORE`のガスコスト更新

SSTORE（ストレージ書き込み）のコストも更新されます。従来は1つのコストとして扱われていましたが、EIP7973では以下の2つのコンポーネントに分離されます。

アカウントタプルの更新コスト（コールド or ウォーム）
ストレージトライの更新コスト

ストレージが更新されると、アカウントのstorage_rootフィールドも変更されます。そのため、既にSSTOREでストレージを更新していれば、アカウントタプルは「ダーティ」（変更済み）状態になっています。この場合、アカウントタプルの更新コストはウォームライト扱いになり、コスト削減の恩恵を受けます。

以下はガスコスト計算の疑似コード（Python記法）です。

python

# 現在値とトランザクション開始時の値を取得
state = evm.message.block_env.state
original_value = get_storage_original(state, evm.message.current_target, key)
current_value = get_storage(state, evm.message.current_target, key)

# アカウント情報を取得（現在の状態とトランザクション開始時の状態）
original_account = get_account_original(state, evm.message.current_target)
account = get_account(state, evm.message.current_target)

gas_cost = Uint(0)

# アカウント書き込みコスト（コールド/ウォーム判定）
if account != original_account:
    gas_cost += GAS_WARM_WRITE          # 既に更新済み → ウォームライト
else:
    gas_cost += GAS_COLD_ACCOUNT_WRITE  # 初回更新 → コールドライト

# スロット固有のコスト（コールドアクセス判定）
if (target, key) not in accessed_storage_keys:
    accessed_storage_keys.add((target, key))
    gas_cost += GAS_COLD_SLOAD

# スロットの値変更に基づくコスト
if original_value == current_value and current_value != new_value:
    if original_value == 0:
        gas_cost += GAS_STORAGE_SET
    else:
        gas_cost += GAS_COLD_STORAGE_WRITE - GAS_COLD_SLOAD
else:
    gas_cost += GAS_WARM_ACCESS

# リファンドカウンター計算
if current_value != new_value:
    if original_value != 0 and current_value != 0 and new_value == 0:
        evm.refund_counter += int(GAS_STORAGE_CLEAR_REFUND)
    if original_value != 0 and current_value == 0:
        evm.refund_counter -= int(GAS_STORAGE_CLEAR_REFUND)
    if original_value == new_value:
        if original_value == 0:
            evm.refund_counter += int(GAS_STORAGE_SET - GAS_WARM_ACCESS)
        else:
            evm.refund_counter += int(GAS_COLD_STORAGE_WRITE - GAS_COLD_SLOAD - GAS_WARM_ACCESS)
        # アカウント書き込みがコールドだった場合のリファンド
        if account == original_account:
            evm.refund_counter += GAS_COLD_ACCOUNT_WRITE

このコードでは、まずget_account_original（トランザクション開始時のアカウント状態）とget_account（現在のアカウント状態）を比較してコールド/ウォームを判定しています。 original_accountとaccountが異なれば、そのトランザクション内で既にアカウントが更新されているためウォームライトとなります。

リファンドカウンターの計算では、スロットがトランザクション開始時の値に戻された場合に差額がリファンドされます。特に注目すべきは最後の条件で、アカウント書き込みがコールドだった場合（account == original_account）にGAS_COLD_ACCOUNT_WRITE分がリファンドされる点です。

EIP7928との互換性

並列実行との互換性のため、現在のトランザクションより前に実行されたトランザクションでブロックレベルアクセスリスト（BAL）にアカウントの更新が記録されている場合、比較対象の値はアカウントトライからではなくBALのエントリから取得されます。これにより、並列実行環境でも正しくコールド/ウォーム判定が機能します。