---
title: "Raiz de estado"
description: "A raiz de estado é o compromisso compacto da Ethereum com o estado global após um bloco. Entenda como ela é calculada, o que provas de conta e armazenamento demonstram e o que não garantem."
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.
# Raiz de estado
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Uma raiz de estado é um compromisso criptográfico de 32 bytes no cabeçalho de um bloco da Ethereum com o estado global após o processamento desse bloco. O estado global associa endereços a contas. Cada conta compromete seu nonce, saldo, raiz de armazenamento e hash do código; a raiz de armazenamento de cada contrato, por sua vez, compromete os slots de armazenamento dessa conta.
A raiz é um resumo, não um snapshot disponível para download. Ela permite que nós comparem resultados calculados de modo independente e que um verificador confira uma prova de conta ou armazenamento contra um bloco confiável. Sozinha, ela não reconstrói o estado, não prova a disponibilidade dos dados, não estabelece a finalidade do bloco nem demonstra que um contrato é economicamente seguro.
“Raiz de estado” é específica do protocolo. Atualmente, a Ethereum compromete o estado da camada de execução com uma trie de Merkle-Patricia modificada. Outras redes podem usar modelos de estado, codificações, funções hash ou estruturas autenticadas diferentes; o mesmo termo não torna suas raízes ou provas intercambiáveis.
## Como funciona
Um cliente de execução começa pelo estado do bloco pai, valida e executa o novo bloco conforme as regras vigentes do protocolo e aplica as alterações resultantes em contas e armazenamento. Esquematicamente:
`S_n = Υ(S_(n-1), B_n)`
Aqui, `S_(n-1)` é o estado pai, `B_n` é todo o processamento definido pelo protocolo para o novo bloco e `S_n` é o estado resultante. O cliente codifica esse estado de forma determinística na trie de estado e calcula o hash raiz. Um cabeçalho válido deve conter o mesmo resultado; uma divergência torna o bloco inválido para o cliente.
Na trie de estado da Ethereum, o caminho de uma conta é derivado do endereço, enquanto a conta codificada contém nonce, saldo, raiz de armazenamento e hash do código. O código do contrato é referenciado por seu hash, e cada contrato tem uma trie de armazenamento separada. Esse aninhamento faz com que a mudança de um slot possa alterar a raiz de armazenamento do contrato, depois a conta codificada e, por fim, a raiz de estado global.
A raiz de estado é diferente das raízes de transações e de recibos no mesmo cabeçalho. A raiz de transações compromete dados ordenados de transações; a raiz de recibos compromete recibos de execução. Nenhuma substitui a outra.
A EIP-1186 define `eth_getProof`, que pode retornar uma prova de conta e as provas de armazenamento solicitadas para um bloco específico. O verificador ainda precisa de um hash de bloco ou raiz de estado autenticados, das regras corretas da trie e de codificação e de uma política adequada de confirmação ou finalidade.
## Exemplo
Suponha que uma transação transfira ETH de Alice para Bob. A execução correta pode mudar o nonce e o saldo de Alice, o saldo de Bob e o saldo do destinatário da taxa. Se a transação chamar um contrato, slots e a raiz de armazenamento do contrato também podem mudar. Essas atualizações geram uma nova raiz de estado global mesmo que a maioria das contas não seja tocada.
Dois clientes honestos que partem do mesmo estado pai e processam o mesmo bloco válido sob as mesmas regras devem calcular a mesma raiz. Se um creditar um valor incorreto ou usar uma codificação errada da trie, sua raiz será diferente da do cabeçalho e ele deverá rejeitar o bloco, em vez de aceitar silenciosamente seu estado local.
Para verificar o saldo de Bob sem baixar todo o estado global, um verificador pode obter o cabeçalho e uma prova de conta. Recalcular o caminho da prova mostra se a conta codificada é consistente com a raiz de estado do cabeçalho. Isso não prova que o cabeçalho escolhido é canônico ou finalizado; essa conclusão vem das verificações de cadeia e finalidade.
## Riscos
- **Raiz não confiável:** Uma prova válida contra uma raiz escolhida por um invasor ou desatualizada prova o ponto de referência errado. Vincule a raiz a um hash de bloco, ID da cadeia e número do bloco verificados.
- **Reorganizações e finalidade:** Uma prova pode estar correta para um bloco que depois sai da cadeia canônica. Ajuste a profundidade de confirmação ou finalidade à tolerância a perdas da aplicação.
- **Erros de codificação:** Hash de endereços, RLP, caminhos de nibbles, nós embutidos e chaves de armazenamento devem seguir exatamente o protocolo. Uma biblioteca genérica de provas binárias de Merkle não basta.
- **Dados ausentes:** A raiz compromete o estado, mas não disponibiliza nós da trie, estado histórico ou serviços de geração de provas. Nós podados podem não fornecer provas antigas.
- **Garantia exagerada:** A concordância das raízes detecta execução inconsistente; não audita contratos, autentica oráculos, protege um endpoint RPC, garante o valor de ativos ou impede que chaves comprometidas autorizem transações.
## Equívocos comuns
- **A raiz de estado armazena todos os saldos.** Ela é um compromisso de tamanho fixo com uma trie codificada; os dados subjacentes devem ser obtidos separadamente.
- **Raízes iguais provam bancos de dados idênticos.** Elas comprometem o mesmo estado global lógico sob o protocolo, mas clientes podem armazenar, indexar, podar ou manter esse estado em cache de formas diferentes.
- **Uma raiz diferente identifica a transação incorreta.** Ela revela divergência no estado final comprometido, não onde começou; os clientes precisam rastrear a execução para diagnosticar.
- **Uma prova de conta válida demonstra finalidade e segurança.** Ela prova apenas consistência com uma raiz. Seleção de cadeia, finalidade, atualidade dos dados, comportamento do contrato e risco econômico continuam separados.
## Tópicos relacionados
- [Modelo baseado em contas](/pt-br/crypto/account-based-model/)
- [Árvore de Merkle](/pt-br/crypto/merkle-tree/)
- [Nó completo](/pt-br/crypto/full-node/)
- [Cliente leve](/pt-br/crypto/light-client/)
- [Confirmação de bloco](/pt-br/crypto/block-confirmation/)
## Fontes
- [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation (acessado em: 2026-08-21)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (acessado em: 2026-08-21)
- [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals (acessado em: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/state-root/index.mdx