Модель состояния на основе аккаунтов

Модель аккаунтов Ethereum: поля аккаунта, корни состояния и хранилища, последовательное исполнение транзакций, газ и откаты, хранение токенов, делегирование EIP-7702, списки доступа, трассировки и финальность.

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Модель на основе аккаунтов представляет состояние исполнения как данные, ключом к которым служит адрес. В исполнительном слое 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 аккаунта, а не устаревшую метку интерфейса.

Аудит перехода состояния в семь шагов

Зафиксируйте точку наблюдения: сеть, chainId, правила fork, номер и хеш блока, временную метку и тег блока, например pending, latest, safe или finalized. Состояние около вершины цепочки может измениться после реорганизации; не объединяйте факты из разных блоков без явной маркировки.
Считайте поля протокольного аккаунта: nonce, нативный balance, storageRoot и codeHash. Если code является индикатором делегирования EIP-7702, определите делегата по правилам этого fork. Для прокси и делегированных аккаунтов отдельно установите code реализации, контроль обновления и схему хранилища.
Найдите прикладные балансы. ETH меняет нативный баланс; баланс ERC-20 обычно меняет mapping в хранилище токен-контракта; разрешения, долг, обеспечение и вознаграждения могут находиться в других контрактах и slots. Decimals токена и logs помогают интерпретации, но не являются дополнительными полями листа аккаунта.
Декодируйте и предварительно проверьте транзакцию верхнего уровня: тип, домен цепочки, подпись, nonce отправителя, получателя или создание, value, input, лимит gas, предельные комиссии и необязательный список доступа либо авторизации EIP-7702. Отправитель должен покрывать value и максимальное обязательство по комиссии. Отклоненная транзакция не включается и не расходует gas в цепочке.
Исполняйте транзакции в порядке блока, начиная с предшествующего состояния. EVM обрабатывает вложенные вызовы сообщений и кадры создания контрактов; у каждого есть вызывающая и вызываемая стороны, value, calldata, gas и статус возврата. Общие чтения и записи делают результат зависимым от порядка. Список доступа EIP-2930 заранее прогревает указанные аккаунты и slots и меняет учет gas, но не запрещает необъявленный доступ и не доказывает безопасность параллельного исполнения.
Примените границы фиксации и отката. Успешный кадр фиксирует состояние и logs, если родительский кадр позднее не откатится. REVERT откатывает записи, переводы value и logs неуспешного кадра, возвращая неиспользованный gas; внешний контракт может перехватить неудачу дочернего вызова и завершиться успешно. У включенной неудачи верхнего уровня квитанция имеет status = 0, однако nonce транзакции отправителя увеличивается, а израсходованный gas оплачивается. Обработка авторизации EIP-7702 имеет собственные правила сохранения, даже если последующее исполнение откатится.
Сверьте состояние после исполнения. Сопоставьте изменения нативных и токен-балансов, изменения хранилища, статус квитанции, использованный 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». Производительность и конфликты зависят от всего протокола и нагрузки.