---
title: "アカウントベースの状態モデル"
description: "アカウントフィールド、状態ルートとストレージルート、順序付きトランザクション実行、Gasとリバート、トークンストレージ、EIP-7702委任、アクセスリスト、トレース、ファイナリティを通じてEthereumのアカウントモデルを理解します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# アカウントベースの状態モデル
> 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 直接の答え
アカウントベースモデルは、実行状態をアドレスをキーとするデータとして表します。Ethereumの実行レイヤーでは、アカウントのリーフに `[nonce, balance, storageRoot, codeHash]` が格納されます。ネイティブの `balance` はwei建てで、コントラクトデータはそのアカウントの `storageRoot` の先にあり、ブロック実行後の `stateRoot` が結果として得られたワールドステートにコミットします。ウォレット、RPCプロバイダー、エクスプローラーはこの状態を読み取って解釈しますが、利用者に代わって正規の残高を保管するわけではありません。
ERC-20残高、アローワンス、貸借債務、担保は通常、保有者のプロトコルアカウントに追加されたフィールドではなく、コントラクトストレージ内の値です。同様に、エクスプローラーの「内部トランザクション」は通常、EVMメッセージコールをトレースから再構成したもので、独自のトランザクションハッシュと送信者nonceを持つ、別途署名されたEthereumトランザクションではありません。
従来の外部所有アカウント（EOA）とコントラクトアカウントの区別は今も有用ですが、EIP-7702を有効化したチェーンでは「EOAのコードは常に空」という前提は絶対ではありません。EOAは委任インジケーター `0xef0100 || address` を持ち、EOAとしてトランザクションを発行する権限を維持しながら、委任先のコードを実行できます。したがって、分類には古いUIラベルではなく、チェーンルールと実際のアカウントコードを用います。
## 状態遷移を監査する7ステップ
1. 観測条件を固定します。ネットワーク、`chainId`、フォーク規則、ブロック番号とハッシュ、タイムスタンプ、さらに `pending`、`latest`、`safe`、`finalized` などのブロックタグを記録します。チェーン先端付近の状態はリオーグで変わり得るため、異なるブロックの事実を無表示で混在させてはいけません。
2. プロトコル上のアカウントフィールド、すなわち `nonce`、ネイティブ `balance`、`storageRoot`、`codeHash` を読み取ります。コードがEIP-7702委任インジケーターなら、そのフォークの規則に従って委任先を解決します。プロキシや委任済みアカウントでは、実装コード、アップグレード管理、ストレージレイアウトも別々に特定します。
3. アプリケーション残高の所在を確認します。ETHはネイティブ残高を変えますが、ERC-20残高は通常、トークンコントラクトのストレージにあるマッピングを変えます。アローワンス、債務、担保、報酬が別のコントラクトやスロットにある場合もあります。トークンの小数桁とログは解釈を助けますが、追加のアカウントリーフフィールドではありません。
4. トップレベル・トランザクションの種別、チェーンドメイン、署名、送信者nonce、宛先または作成、value、入力、Gas上限、手数料上限、任意のアクセスリストまたはEIP-7702認可をデコードして事前確認します。送信者はvalueと最大手数料負担を賄う必要があります。拒否されたトランザクションはブロックに含まれず、オンチェーンGasも消費しません。
5. 直前の状態から、ブロック内の順序どおりにトランザクションを実行します。EVMはネストしたメッセージコールとコントラクト作成フレームを処理し、各フレームは呼出元、呼出先、value、calldata、Gas、戻り状態を持ちます。共有された読み書きにより、結果は順序に依存します。EIP-2930アクセスリストは指定したアカウントとスロットをウォーム化してGas計算を変えますが、未宣言アクセスを禁止せず、安全な並列実行を証明するものでもありません。
6. コミットとロールバックの境界を適用します。成功したフレームの状態とログは、後で親がリバートしない限りコミットされます。`REVERT` は失敗フレームの書き込み、value移転、ログをロールバックし、未使用Gasを返します。外側のコントラクトは子呼び出しの失敗を捕捉して成功を続けることができます。ブロックに含まれたトップレベル失敗のレシートは `status = 0` ですが、送信者のトランザクションnonceは増え、消費Gasも支払われます。EIP-7702の認可処理には、後続実行がリバートしても適用される独自の永続化規則があります。
7. 実行後の状態を照合します。ネイティブおよびトークン残高差、ストレージ変更、レシート状態、Gas使用量、実効Gas価格、ログ、プロバイダーのトレースを、ブロックがコミットしたルートと突き合わせます。トレースはプロバイダーが再構成したもので、別個のコンセンサストランザクションではありません。必要なファイナリティを待った後、置換、リオーグ、インデクサー修正、ブリッジ、ロールアップ、会計上の戻入を明示的に処理します。
## 4つの計算例
- **EIP-1559のETH送金。** Aの開始残高は `5 ETH`、nonceは `12`、Bの開始残高は `1 ETH` です。Aは `1 ETH` を送り、`21,000 gas`、ベースフィー `20 gwei`、優先手数料上限 `3 gwei`、最大手数料 `40 gwei` を指定します。実効Gas価格は `min(40, 20 + 3) = 23 gwei`、総手数料は `21,000 × 23 gwei = 0.000483 ETH` で、このうち `0.000420 ETH` がベースフィーとしてバーンされ、`0.000063 ETH` が優先手数料です。署名時点の最大必要額は `1 ETH + 21,000 × 40 gwei = 1.000840 ETH` です。最終残高はAが `3.999517 ETH`、Bが `2 ETH`、Aのnonceは `13` です。
- **ブロックに含まれたリバート取引。** Aの開始残高は `2 ETH`、nonceは `7` です。Aが `0.50 ETH` を伴ってコントラクトを呼び出し、トップレベル実行が `80,000 gas` 消費後にリバートしたとします。実効Gas価格は `25 gwei` なので、手数料は `80,000 × 25 gwei = 0.002000 ETH` です。コントラクトストレージの書き込み、ログ、`0.50 ETH` の移転はロールバックしますが、Aの最終残高は `1.998000 ETH`、nonceは `8`、レシートは `status = 0` です。子呼び出しの失敗を捕捉した場合は、外側のレシートが `status = 1` になることもあります。
- **トークン残高はコントラクトストレージ。** トークンコントラクトにAliceが `1,000 units`、Bobが `200 units` と記録されています。`250 units` の送付に成功すると、Aliceは `750 units`、Bobは `450 units` となり、合計 `1,200 units` は変わりません。Aliceのトップレベル取引が `60,000 gas × 20 gwei = 0.001200 ETH` を使ったなら、ネイティブETH残高は別途その手数料分減少します。トークンアカウントの `storageRoot` とグローバルな `stateRoot` は変わりますが、トークン元本がAliceのネイティブアカウント残高になることはありません。
- **EIP-7702の永続化境界。** スポンサーが、nonce `5` のアカウントAから実装Dへの認可を含むset-codeトランザクションを提出します。プロトコルは `23-byte` のインジケーター `0xef0100 || 20-byte address` を書き込み、Aの認可nonceを `6` に増やします。その外側のトランザクションで後続実行がリバートしても、処理済み委任インジケーターと認可nonceは残ります。これは、失敗した呼び出しが通常のEVMストレージへ行った書き込みのロールバック境界とは異なります。
## リスクと管理策
- 誤ったチェーン、フォーク、ブロックハッシュ、ブロックタグを読むと、内部的に不整合な状態スナップショットになります。
- 古い、または信頼できないRPCはチェーン先端状態を欠落、遅延、誤報する可能性があります。
- pending nonceの競合、欠番、置換により、待機中取引の前提が無効になる可能性があります。
- ウォレットの「キャンセル」は通常、プロトコル上の削除ではなく置換トランザクションです。
- valueと最大手数料を賄う残高がなければ、トランザクションは含まれません。
- ベースフィーの変動や手数料上限の誤りは、取り込みを遅らせたり費用を変えたりします。
- EIP-7702コードにより、古いアカウント判定法がEOAを誤分類する可能性があります。
- 悪意ある委任先、初期化不備、認可リプレイがEIP-7702アカウントを侵害する可能性があります。
- プロキシのアップグレードとデリゲートコールにより、コードとストレージの解釈が時間とともに変わる場合があります。
- 鍵、署名ドメイン、チェーンIDの誤りは盗難やリプレイを認可し得ます。
- リエントランシーと共有状態の順序により、一回の実行中に残高が変わり得ます。
- 子呼び出しの失敗を捕捉し、外側のトランザクションが成功と表示される場合があります。
- トップレベルのリバートやGas枯渇でも、Gasを消費して送信者nonceが増えます。
- 小数桁、送金手数料、リベース、フックのあるトークンでは、単純な残高計算が成立しない場合があります。
- ウォレット残高だけの照合では、アローワンス、債務、担保、報酬を見落とします。
- ログは欠落、リバート、誤解を招く表示があり得て、最終状態を証明するには不十分な場合があります。
- エクスプローラーの「内部トランザクション」とプロバイダーのトレースは、再構成方法により異なる場合があります。
- アクセスリストは不完全、重複、非経済的になり得て、読み書きセットをロックしません。
- 共有状態の順序、優先手数料、MEVが実行結果を変える可能性があります。
- リオーグ、プルーニング、証明の利用不能、L2システム遷移、ブリッジのファイナリティが会計を反転または不明瞭にする可能性があります。
## よくある誤解
- 「ウォレットがオンチェーン残高を保存する。」ウォレットは認証情報を保持し、ネットワークから取得した状態を表示します。
- 「すべてのアドレスは、コードのないEOAか通常のコントラクトのどちらかに永久に属する。」EIP-7702委任により、このコード判定法は変わります。
- 「表示される送金はすべて別個のEthereumトランザクションである。」トークンイベントと内部メッセージコールのトレースは、トップレベルの署名済み取引ではありません。
- 「失敗した取引は何も変えず、費用もかからない。」ブロックに含まれた失敗はGasを消費し、送信者nonceを進める場合があります。
- 「アカウントモデルやアクセスリストはUTXOより高速な並列実行を保証する。」性能と競合はプロトコル全体とワークロードに依存します。
## 関連トピック
- [状態ルート](/ja/crypto/state-root/)
- [UTXOモデル](/ja/crypto/utxo-model/)
- [アカウント抽象化](/ja/crypto/account-abstraction/)
## 出典
- [Ethereumアカウント](https://ethereum.org/developers/docs/accounts/)
- [Ethereum Yellow Paper：プログラム可能なブロックチェーンEthereumの形式仕様](https://ethereum.github.io/yellowpaper/paper.pdf)
- [トランザクション](https://ethereum.org/developers/docs/transactions/)
- [ブロック](https://ethereum.org/developers/docs/blocks/)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)
- [EIP-7702：EOAへのコード設定](https://eips.ethereum.org/EIPS/eip-7702)
- [EIP-2930：任意のアクセスリスト](https://eips.ethereum.org/EIPS/eip-2930)
- [プルーフ・オブ・ステーク（PoS）](https://ethereum.org/developers/docs/consensus-mechanisms/pos/)
Source: https://wiki.fcontext.com/ja/crypto/account-based-model/index.mdx