Ir para o conteúdo
Financial Context Wiki

Raiz de estado

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.

Atualizado

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

Fontes

Navegação

Pesquisar na wiki...