---
title: "Modelo de estado baseado em contas"
description: "Entenda o modelo baseado em contas do Ethereum por meio de campos da conta, raizes de estado e armazenamento, execucao ordenada, gas e reversoes, armazenamento de tokens, delegacao EIP-7702, listas de acesso, traces e finalidade."
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.
# Modelo de estado baseado em contas
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Um modelo baseado em contas representa o estado de execucao como dados indexados por endereco. Na camada de execucao do Ethereum, uma folha de conta contem `[nonce, balance, storageRoot, codeHash]`. O `balance` nativo e denominado em wei; os dados do contrato ficam por tras do `storageRoot` da conta; e o `stateRoot` posterior a execucao do bloco compromete o estado global resultante. Carteira, provedor RPC ou explorador le e interpreta esse estado, mas nao guarda o saldo canonico pelo usuario.
Saldos ERC-20, allowances, divida de emprestimo e garantias normalmente sao valores no armazenamento de contratos, nao campos extras da conta do titular. Da mesma forma, uma "transacao interna" exibida pelo explorador costuma ser uma chamada de mensagem EVM reconstruida por trace, nao uma transacao Ethereum assinada separadamente com hash e nonce proprios.
A distincao tradicional entre externally owned account (EOA) e conta de contrato continua util, mas "uma EOA sempre tem codigo vazio" deixou de ser absoluta em uma cadeia com EIP-7702. Uma EOA pode carregar o indicador `0xef0100 || address` e executar o codigo delegado mantendo a autoridade para iniciar transacoes. A classificacao deve usar regras da cadeia e codigo real, nao um rotulo antigo da interface.
## Auditoria da transicao de estado em sete etapas
1. Fixe a observacao: rede, `chainId`, regras do fork, numero e hash do bloco, timestamp e tag como `pending`, `latest`, `safe` ou `finalized`. O estado proximo da ponta pode mudar apos reorganizacao; nao misture dados de blocos diferentes sem rotulo.
2. Leia os campos de protocolo: `nonce`, `balance` nativo, `storageRoot` e `codeHash`. Se o codigo for indicador EIP-7702, resolva o delegado segundo o fork. Em proxies e contas delegadas, identifique separadamente implementacao, controle de upgrade e layout de armazenamento.
3. Localize saldos da aplicacao. ETH altera o saldo nativo; ERC-20 geralmente altera um mapping no contrato do token; allowances, divida, garantia e recompensas podem estar em outros contratos e slots. Decimais e logs ajudam a interpretar, mas nao sao campos da folha.
4. Decodifique e faca a prechecagem da transacao superior: tipo, dominio de cadeia, assinatura, nonce do remetente, destino ou criacao, valor, input, limite de gas, tetos de taxa e lista de acesso ou autorizacoes EIP-7702 opcionais. O remetente deve cobrir valor e compromisso maximo de taxas. Transacao rejeitada nao e incluida nem consome gas on-chain.
5. Execute em ordem de bloco a partir do estado anterior. A EVM processa chamadas de mensagem aninhadas e frames de criacao, cada um com caller, callee, valor, calldata, gas e resultado. Leituras e escritas compartilhadas tornam o resultado dependente da ordem. A lista EIP-2930 preaquece contas e slots e muda a contabilidade de gas; nao proibe acesso nao declarado nem prova paralelismo seguro.
6. Aplique fronteiras de commit e rollback. Frame bem-sucedido confirma estado e logs salvo reversao posterior do pai. `REVERT` desfaz escritas, transferencias e logs do frame falho e devolve gas nao usado; o contrato externo pode capturar falha filha e ainda ter sucesso. Falha superior incluida tem recibo `status = 0`, mas incrementa o nonce e paga gas consumido. Autorizacoes EIP-7702 tem persistencia propria mesmo se a execucao posterior reverter.
7. Reconcilie o pos-estado. Compare variacoes de ETH e tokens, armazenamento, status do recibo, gas usado, preco efetivo, logs e traces do provedor com as raizes comprometidas do bloco. Trate traces como reconstrucoes, nao transacoes de consenso. Aguarde a finalidade exigida e trate substituicoes, reorgs, revisoes de indexadores, bridges, rollups e estornos contabeis.
## Quatro exemplos resolvidos
- **Transferencia ETH EIP-1559.** A comeca com `5 ETH` e nonce `12`; B com `1 ETH`. A envia `1 ETH` usando `21,000 gas`, base fee `20 gwei`, priority cap `3 gwei` e max fee `40 gwei`. O preco efetivo e `min(40, 20 + 3) = 23 gwei`; a taxa total e `21,000 × 23 gwei = 0.000483 ETH`, com `0.000420 ETH` queimados e `0.000063 ETH` de prioridade. O requisito maximo na assinatura e `1 ETH + 21,000 × 40 gwei = 1.000840 ETH`. Saldos finais: A `3.999517 ETH`, B `2 ETH`; nonce de A `13`.
- **Transacao incluida que reverte.** A comeca com `2 ETH` e nonce `7`. Chama contrato com `0.50 ETH`; a execucao superior reverte apos `80,000 gas` a `25 gwei`, logo a taxa e `80,000 × 25 gwei = 0.002000 ETH`. Escritas, logs e transferencia de `0.50 ETH` revertem, mas A termina com `1.998000 ETH`, nonce `8` e recibo `status = 0`. Uma falha filha capturada pode coexistir com recibo externo `status = 1`.
- **Saldo de token e armazenamento contratual.** O contrato registra Alice `1,000 units` e Bob `200 units`. Transferir `250 units` deixa Alice `750 units` e Bob `450 units`, preservando `1,200 units`. Se a transacao de Alice usa `60,000 gas × 20 gwei = 0.001200 ETH`, seu ETH nativo cai separadamente. Mudam o `storageRoot` do token e o `stateRoot` global; o principal nunca foi saldo nativo de Alice.
- **Persistencia EIP-7702.** Um patrocinador envia set-code transaction com autorizacao de A no nonce `5` para delegar a D. O protocolo grava o indicador de `23-byte` `0xef0100 || 20-byte address` e eleva o nonce de autoridade de A a `6`. Se a execucao externa reverter depois, indicador e nonce ja processados permanecem. E uma fronteira diferente do storage EVM comum escrito pela chamada falha.
## Riscos e controles
- Cadeia, fork, hash ou tag de bloco errados geram snapshot incoerente.
- RPC desatualizado ou nao confiavel pode omitir ou informar mal o estado da ponta.
- Corridas, lacunas e substituicoes de nonce pendente invalidam premissas.
- "Cancelar" na carteira geralmente substitui a transacao, nao a apaga do protocolo.
- Saldo insuficiente para valor e taxa maxima impede inclusao.
- Movimento da base fee ou erro de teto atrasa inclusao ou muda custo.
- EIP-7702 pode fazer heuristicas antigas classificarem uma EOA incorretamente.
- Delegado malicioso, inicializacao falha ou replay compromete conta EIP-7702.
- Upgrades e delegate calls mudam a interpretacao de codigo e storage.
- Erros de chave, dominio ou chain ID permitem roubo ou replay.
- Reentrancy e ordenacao de estado compartilhado alteram saldos na execucao.
- Chamada filha pode falhar e ser capturada enquanto a transacao externa tem sucesso.
- Revert superior ou out-of-gas consome gas e incrementa nonce.
- Decimais, fee-on-transfer, rebasing e hooks invalidam aritmetica simples.
- Allowances, divida, garantia e recompensas podem faltar na conciliacao.
- Logs podem faltar, reverter, enganar ou nao provar o estado final.
- "Transacoes internas" e traces variam por serem visoes reconstruidas.
- Access list pode ser incompleta, duplicada ou antieconomica e nao trava o conjunto de acesso.
- Ordenacao, priority fees e MEV podem mudar resultados.
- Reorgs, pruning, provas indisponiveis, transicoes L2 e finalidade de bridges podem reverter ou ocultar registros.
## Equivocos comuns
- "A carteira armazena o saldo on-chain." Ela guarda credenciais e apresenta estado da rede.
- "Todo endereco e para sempre EOA sem codigo ou contrato comum." EIP-7702 muda essa heuristica.
- "Toda transferencia exibida e uma transacao Ethereum." Eventos e traces nao sao transacoes superiores assinadas.
- "Transacao falha nada muda e nada custa." Se incluida, consome gas e avanca nonce.
- "Modelo de contas ou access list garante mais paralelismo que UTXO." Desempenho e conflitos dependem do protocolo e carga.
## Topicos relacionados
- [Raiz de estado](/pt-br/crypto/state-root/)
- [Modelo UTXO](/pt-br/crypto/utxo-model/)
- [Abstracao de contas](/pt-br/crypto/account-abstraction/)
## Fontes
- [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/pt-br/crypto/account-based-model/index.mdx