---
title: "Модель состояния на основе аккаунтов"
description: "Модель аккаунтов Ethereum: поля аккаунта, корни состояния и хранилища, последовательное исполнение транзакций, газ и откаты, хранение токенов, делегирование EIP-7702, списки доступа, трассировки и финальность."
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, а не отдельно подписанную транзакцию Ethereum с собственными хешем транзакции и nonce отправителя.
Традиционное различие между внешне управляемым аккаунтом (EOA) и контрактным аккаунтом остается полезным, но утверждение «у EOA всегда пустой code» уже не абсолютно для цепочки с активированным EIP-7702. EOA может содержать индикатор делегирования `0xef0100 || address` и исполнять code делегата, сохраняя полномочие EOA на отправку транзакций. Поэтому классификация должна учитывать правила цепочки и фактический code аккаунта, а не устаревшую метку интерфейса.
## Аудит перехода состояния в семь шагов
1. Зафиксируйте точку наблюдения: сеть, `chainId`, правила fork, номер и хеш блока, временную метку и тег блока, например `pending`, `latest`, `safe` или `finalized`. Состояние около вершины цепочки может измениться после реорганизации; не объединяйте факты из разных блоков без явной маркировки.
2. Считайте поля протокольного аккаунта: `nonce`, нативный `balance`, `storageRoot` и `codeHash`. Если code является индикатором делегирования EIP-7702, определите делегата по правилам этого fork. Для прокси и делегированных аккаунтов отдельно установите code реализации, контроль обновления и схему хранилища.
3. Найдите прикладные балансы. ETH меняет нативный баланс; баланс ERC-20 обычно меняет mapping в хранилище токен-контракта; разрешения, долг, обеспечение и вознаграждения могут находиться в других контрактах и slots. Decimals токена и logs помогают интерпретации, но не являются дополнительными полями листа аккаунта.
4. Декодируйте и предварительно проверьте транзакцию верхнего уровня: тип, домен цепочки, подпись, nonce отправителя, получателя или создание, value, input, лимит gas, предельные комиссии и необязательный список доступа либо авторизации EIP-7702. Отправитель должен покрывать value и максимальное обязательство по комиссии. Отклоненная транзакция не включается и не расходует gas в цепочке.
5. Исполняйте транзакции в порядке блока, начиная с предшествующего состояния. EVM обрабатывает вложенные вызовы сообщений и кадры создания контрактов; у каждого есть вызывающая и вызываемая стороны, value, calldata, gas и статус возврата. Общие чтения и записи делают результат зависимым от порядка. Список доступа EIP-2930 заранее прогревает указанные аккаунты и slots и меняет учет gas, но не запрещает необъявленный доступ и не доказывает безопасность параллельного исполнения.
6. Примените границы фиксации и отката. Успешный кадр фиксирует состояние и logs, если родительский кадр позднее не откатится. `REVERT` откатывает записи, переводы value и logs неуспешного кадра, возвращая неиспользованный gas; внешний контракт может перехватить неудачу дочернего вызова и завершиться успешно. У включенной неудачи верхнего уровня квитанция имеет `status = 0`, однако nonce транзакции отправителя увеличивается, а израсходованный gas оплачивается. Обработка авторизации EIP-7702 имеет собственные правила сохранения, даже если последующее исполнение откатится.
7. Сверьте состояние после исполнения. Сопоставьте изменения нативных и токен-балансов, изменения хранилища, статус квитанции, использованный gas, фактическую цену gas, logs и трассировки провайдера с зафиксированными корнями блока. Считайте traces реконструкцией провайдера, а не отдельными консенсусными транзакциями. Дождитесь требуемой финальности, затем явно обработайте замены, реорганизации, исправления индексатора, мосты, rollups и обратные бухгалтерские записи.
## Четыре разобранных примера
- **Перевод ETH по EIP-1559.** У A изначально `5 ETH` и nonce `12`, у B — `1 ETH`. A отправляет `1 ETH`, используя `21,000 gas`, при base fee `20 gwei`, priority cap `3 gwei` и max fee `40 gwei`. Фактическая цена gas равна `min(40, 20 + 3) = 23 gwei`; общая комиссия — `21,000 × 23 gwei = 0.000483 ETH`, из которых `0.000420 ETH` составляют сожженную base fee, а `0.000063 ETH` — priority fee. Максимальное требование на момент подписи равно `1 ETH + 21,000 × 40 gwei = 1.000840 ETH`. Итоговые балансы: у A `3.999517 ETH`, у B `2 ETH`, nonce A равен `13`.
- **Включенная транзакция с откатом.** У A изначально `2 ETH` и nonce `7`. A вызывает контракт с `0.50 ETH`; исполнение верхнего уровня откатывается после `80,000 gas` при фактической цене `25 gwei`, поэтому комиссия равна `80,000 × 25 gwei = 0.002000 ETH`. Записи хранилища контракта, logs и перевод `0.50 ETH` откатываются, но у A остается `1.998000 ETH`, nonce `8`, а квитанция содержит `status = 0`. Перехваченная A ошибка дочернего вызова, напротив, может сочетаться с внешней квитанцией `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.** Спонсор отправляет set-code транзакцию с авторизацией аккаунта A при nonce `5` на делегирование реализации D. Протокол записывает индикатор длиной `23-byte` — `0xef0100 || 20-byte address` — и увеличивает nonce полномочия A до `6`. Если последующее исполнение во внешней транзакции откатится, уже обработанные индикатор делегирования и nonce авторизации сохранятся. Это не та же граница отката, что у обычного хранилища EVM, записанного неуспешным вызовом.
## Риски и меры контроля
- Чтение неверной цепочки, fork, хеша или тега блока создает внутренне несогласованный снимок состояния.
- Устаревший или ненадежный RPC может пропустить, задержать или неверно показать состояние вершины.
- Гонки, разрывы и замены pending nonce могут нарушить предположения об очереди.
- «Отмена» в кошельке обычно является заменяющей транзакцией, а не удалением на уровне протокола.
- Недостаточный баланс для value и максимальных комиссий не позволяет включить транзакцию.
- Изменение base fee или ошибки fee cap могут задержать включение или изменить стоимость.
- Code EIP-7702 может привести к ошибочной классификации EOA по старым эвристикам.
- Вредоносный делегат, ошибка инициализации или повтор авторизации могут скомпрометировать аккаунт EIP-7702.
- Обновления прокси и delegate calls могут со временем менять интерпретацию code и хранилища.
- Ошибки ключа, домена подписи или chain ID могут разрешить кражу или повтор.
- Reentrancy и порядок общего состояния могут изменить балансы в одном исполнении.
- Дочерний вызов может завершиться неудачей и быть перехвачен, а внешняя транзакция останется успешной.
- Откат верхнего уровня или out-of-gas все равно расходует gas и увеличивает nonce отправителя.
- Decimals токена, комиссия за перевод, rebasing и hooks могут нарушить простую арифметику баланса.
- Разрешения, долг, обеспечение и вознаграждения могут быть упущены при сверке только балансов кошелька.
- Logs могут отсутствовать, откатываться, вводить в заблуждение или быть недостаточными для доказательства итогового состояния.
- «Внутренние транзакции» обозревателя и traces провайдера могут различаться, поскольку это реконструкции.
- Список доступа может быть неполным, дублированным или невыгодным и не фиксирует набор чтения и записи.
- Порядок общего состояния, priority fees и MEV могут изменить результат исполнения.
- Реорганизации, pruning, недоступные proofs, переходы L2 и финальность мостов могут обратить или скрыть учет.
## Распространенные заблуждения
- «Кошелек хранит баланс в цепочке». Кошелек хранит учетные данные и показывает состояние, полученное из сети.
- «Каждый адрес навсегда остается либо EOA без code, либо обычным контрактом». Делегирование EIP-7702 меняет эту эвристику.
- «Каждый показанный перевод — отдельная транзакция Ethereum». События токенов и трассировки внутренних вызовов сообщений не являются подписанными транзакциями верхнего уровня.
- «Неудачная транзакция ничего не меняет и ничего не стоит». Включенная неудача может расходовать gas и увеличивать nonce отправителя.
- «Модель аккаунтов или список доступа гарантирует более быстрое параллельное исполнение, чем UTXO». Производительность и конфликты зависят от всего протокола и нагрузки.
## Связанные темы
- [Корень состояния](/ru/crypto/state-root/)
- [Модель UTXO](/ru/crypto/utxo-model/)
- [Абстракция аккаунта](/ru/crypto/account-abstraction/)
## Источники
- [Ethereum accounts](https://ethereum.org/developers/docs/accounts/)
- [Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain](https://ethereum.github.io/yellowpaper/paper.pdf)
- [Transactions](https://ethereum.org/developers/docs/transactions/)
- [Blocks](https://ethereum.org/developers/docs/blocks/)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)
- [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702)
- [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/)
Source: https://wiki.fcontext.com/ru/crypto/account-based-model/index.mdx