Trie de estado

O que é uma trie de estado em cripto?

Uma trie de estado é uma estrutura de dados criptográfica que armazena o estado atual de uma blockchain de forma que possa ser atualizada, verificada e resumida eficientemente por um único hash raiz.

Em blockchains no estilo Ethereum, a trie de estado é a estrutura que mapeia endereços de contas para dados de conta, como saldos, nonces, raízes de armazenamento de contratos inteligentes e hashes de código.

A documentação oficial da Merkle Patricia Trie da Ethereum explica que a Ethereum possui uma trie de estado global, atualizada sempre que um cliente processa um bloco.

Essa trie de estado global é uma das partes mais importantes da camada de execução da Ethereum, pois representa o estado ativo da rede após a aplicação das transações.

Uma trie de estado não é o mesmo que uma lista de transações históricas.

As transações descrevem o que aconteceu, enquanto a trie de estado descreve como a blockchain está agora, após essas transações terem alterado saldos, armazenamento de contratos e dados de contas.

Por exemplo, se um usuário envia ETH de uma conta para outra, a transação é registrada em um bloco, mas a trie de estado muda porque os saldos de duas contas são atualizados.

Se um usuário chama um contrato inteligente, a transação é registrada em um bloco, mas a trie de estado pode mudar porque o armazenamento do contrato, os saldos e os nonces das contas podem ser atualizados.

Em termos simples, a trie de estado é o banco de dados autenticado do estado atual das contas na blockchain.

Por que a trie de estado é importante

A trie de estado é importante porque as blockchains precisam de uma forma segura de comprovar qual é o estado atual.

O estado de uma blockchain pode incluir milhões de contas, contratos inteligentes, saldos, entradas de armazenamento e outros valores.

Os nós precisam concordar sobre esse estado para decidir se novas transações são válidas.

Se o remetente não tiver saldo suficiente, a transação deverá falhar.

Se um slot de armazenamento de contrato tiver determinado valor, uma chamada de contrato inteligente poderá se comportar de forma diferente.

Se um nonce já tiver sido usado, uma transação repetida não deverá ser aceita.

A trie de estado oferece aos clientes uma estrutura determinística para armazenar e verificar esses valores.

Ela também produz uma única raiz de estado que pode ser inserida no cabeçalho de um bloco.

Se dois clientes processarem o mesmo bloco e chegarem à mesma raiz de estado, haverá fortes evidências de que concordam sobre o estado resultante.

Isso torna a trie de estado essencial para o consenso da blockchain, a verificação, as provas para clientes leves, a sincronização de nós, a execução de contratos inteligentes e a integridade dos dados.

Trie de estado e raiz de estado

A raiz de estado é o hash raiz da trie de estado depois que todas as transações de um bloco foram processadas.

Os cabeçalhos de blocos da Ethereum incluem um stateRoot, que se compromete com todo o estado global naquele bloco.

A documentação da Merkle Patricia Trie da Ethereum explica que os cabeçalhos de blocos da camada de execução da Ethereum contêm raízes para a trie de estado, a trie de transações e a trie de recibos.

A raiz de estado é importante porque representa um compromisso criptográfico compacto com um banco de dados muito maior.

Um usuário não precisa baixar todos os valores de contas e de armazenamento de contratos para verificar uma afirmação específica se houver uma prova válida disponível.

Em vez disso, o usuário pode verificar que um valor pertence ao estado comprometido pela raiz de estado.

Se qualquer saldo de conta, raiz de armazenamento de contrato, nonce ou hash de código mudar, o caminho de hashes que leva à raiz também mudará.

Isso significa que um estado diferente deverá produzir uma raiz de estado diferente.

Portanto, a raiz de estado é uma impressão digital do estado completo da blockchain em um bloco específico.

Ela ajuda a transformar um enorme banco de dados de estado em um único valor verificável.

Como funciona a trie de estado

A trie de estado da Ethereum usa uma Merkle Patricia Trie modificada.

Uma Merkle Patricia Trie combina ideias de árvores de Merkle, tries radix e tries Patricia.

Uma trie é uma estrutura de chave-valor semelhante a uma árvore, na qual o caminho pela árvore é baseado na chave.

Uma trie Patricia compacta caminhos para que a árvore não desperdice espaço com longas cadeias de nós vazios.

Uma árvore de Merkle adiciona hashes criptográficos para que os dados possam ser verificados por caminhos de hash.

A Ethereum combina esses recursos para que os clientes possam armazenar o estado das contas, atualizá-lo eficientemente e verificá-lo usando hashes raiz e provas de Merkle.

Na trie de estado da Ethereum, o caminho é baseado no hash Keccak-256 do endereço da conta.

O valor armazenado nesse caminho é o objeto de conta codificado em RLP.

A documentação oficial da Ethereum afirma que um objeto de conta Ethereum é um array de quatro itens contendo nonce, balance, storageRoot e codeHash.

Esse design torna cada conta acessível por meio de um caminho criptográfico determinístico.

Quais dados são armazenados na trie de estado?

A trie de estado armazena objetos de conta, em vez de cada valor de armazenamento de contrato diretamente na trie global principal.

Cada objeto de conta Ethereum contém um nonce.

Cada objeto de conta Ethereum contém um saldo.

Cada objeto de conta Ethereum contém um storageRoot.

Cada objeto de conta Ethereum contém um codeHash.

O nonce ajuda a evitar a repetição de transações e acompanha a atividade da conta.

O saldo registra a quantidade de moeda nativa mantida pela conta.

O storageRoot aponta para outra trie que armazena o armazenamento do contrato inteligente daquela conta.

O codeHash se compromete com o bytecode do contrato inteligente associado a uma conta de contrato.

Contas controladas externamente geralmente têm código vazio e armazenamento de contrato vazio.

Contas de contratos inteligentes podem ter código e armazenamento que afetam sua execução.

Trie de estado vs. trie de armazenamento

A trie de estado e a trie de armazenamento são relacionadas, mas diferentes.

A trie de estado é a estrutura global que mapeia endereços de contas para objetos de conta.

Uma trie de armazenamento é uma trie separada usada para o armazenamento de uma conta específica de contrato inteligente.

A documentação da Ethereum explica que há uma trie de armazenamento separada para cada conta que possui armazenamento de contrato.

O objeto de conta na trie de estado armazena um storageRoot, que é a raiz da trie de armazenamento dessa conta.

Isso significa que a trie de estado global não contém diretamente todos os slots de armazenamento de todos os contratos.

Em vez disso, ela contém objetos de conta, e cada conta de contrato pode apontar para sua própria trie de armazenamento.

Por exemplo, um contrato de token pode armazenar saldos de usuários em sua própria trie de armazenamento de contrato.

A trie de estado global armazena o objeto de conta do contrato de token, e esse objeto aponta para a raiz de armazenamento do contrato de token.

Esse design em camadas ajuda a separar o estado no nível de conta do armazenamento no nível de contrato.

Trie de estado vs. trie de transações

A trie de estado é diferente da trie de transações.

A trie de estado armazena o estado de conta resultante após a execução das transações.

A trie de transações armazena as transações incluídas em um bloco específico.

Cada bloco possui sua própria trie de transações.

A trie de transações não é atualizada continuamente entre blocos da mesma forma que a trie de estado global.

A trie de estado evolui de bloco para bloco à medida que transações alteram saldos de contas e o armazenamento dos contratos.

Uma transação pode ser entendida como uma instrução.

A trie de estado pode ser entendida como o resultado após a aplicação das instruções.

Essa distinção é importante porque uma blockchain não é apenas um registro ordenado de transações.

Ela também é uma máquina de estados, na qual cada transação válida move o sistema de um estado para o próximo.

Trie de estado vs. trie de recibos

A trie de estado também é diferente da trie de recibos.

A trie de recibos armazena os recibos de transações de um bloco.

Um recibo registra resultados de execução, como status, gas utilizado, logs e dados de eventos.

A trie de estado registra o estado final das contas após a execução.

Os recibos ajudam os aplicativos a entender o que aconteceu durante a execução da transação.

A trie de estado ajuda os clientes a verificar qual passou a ser o estado da blockchain após a execução.

Por exemplo, uma transação de contrato inteligente pode emitir um evento registrado em um recibo.

A mesma transação também pode alterar o armazenamento do contrato registrado por meio da trie de estado e da trie de armazenamento.

As duas estruturas são importantes, mas respondem a perguntas diferentes.

A trie de recibos responde o que a transação produziu, enquanto a trie de estado responde qual é o estado atual da cadeia.

Nós da Merkle Patricia Trie

A Merkle Patricia Trie modificada da Ethereum usa vários tipos de nós.

A documentação oficial da Ethereum descreve nós de ramificação, nós folha, nós de extensão e nós vazios.

Um nó de ramificação pode apontar para até 16 caminhos filhos possíveis e também pode conter um valor.

Um nó folha armazena o caminho codificado final e o valor.

Um nó de extensão compacta um segmento de caminho compartilhado para que a trie possa evitar longas cadeias de nós esparsos.

Esse design é útil porque as chaves da Ethereum são longas e esparsas.

Sem compressão de caminho, muitas buscas desperdiçariam etapas em caminhos vazios ou sem ramificações.

Ao usar nós de extensão e nós folha, a Ethereum torna a trie mais compacta do que uma trie radix básica.

Ao usar hashes, a Ethereum torna a trie verificável criptograficamente.

Essa combinação explica por que a estrutura é chamada de Merkle Patricia Trie modificada.

Codificação RLP e hashing

A Ethereum usa a codificação Recursive Length Prefix, frequentemente chamada de RLP, para serializar muitas estruturas de dados na camada de execução.

Na trie de estado, os objetos de conta são codificados em RLP antes de serem inseridos como valores.

Os nós da trie também são codificados antes de serem submetidos a hash ou armazenados.

A documentação da Merkle Patricia Trie da Ethereum explica que, quando um nó referencia outro, a referência pode ser o hash Keccak-256 do nó codificado em RLP, dependendo do comprimento codificado.

Isso é importante porque cada nó deve ser codificado de forma determinística.

Se dois clientes codificarem o mesmo estado de forma diferente, poderão calcular raízes diferentes e não chegar a um consenso.

Assim, a codificação determinística é um detalhe crítico para o consenso.

O hashing também torna alterações maliciosas visíveis, pois mudar um valor altera o hash do nó e o caminho de hashes até a raiz.

O resultado é um banco de dados de chave-valor verificável, no qual um hash raiz se compromete com todos os valores incluídos.

Essa é a base criptográfica das provas de estado.

Provas de estado

Uma prova de estado é uma prova criptográfica de que determinada conta ou valor de armazenamento existe no estado comprometido por uma raiz de estado específica.

A proposta EIP-1186 eth_getProof explica que o estado baseado em árvores de Merkle da Ethereum permite verificar valores de contas e de armazenamento por meio de provas de Merkle.

Uma prova geralmente contém os nós necessários para reconstruir o caminho do valor-alvo até a raiz de estado.

Se o hash reconstruído corresponder à raiz de estado confiável, o valor poderá ser verificado sem confiar integralmente no provedor de dados.

Isso é útil para clientes leves, bridges, aplicativos cross-chain, carteiras móveis, auditores e sistemas de contratos inteligentes que precisam verificar estados externos.

Por exemplo, uma prova pode mostrar que uma conta tinha determinado saldo em determinado bloco.

Uma prova também pode mostrar que um slot de armazenamento de contrato tinha determinado valor em determinado bloco.

As provas de estado são poderosas porque permitem verificação seletiva, em vez do download de todo o banco de dados de estado.

A trie de estado torna essas provas possíveis.

Sem uma estrutura de estado autenticada, os usuários precisariam confiar muito mais em provedores RPC e indexadores.

eth_getProof

eth_getProof é um método JSON-RPC da Ethereum projetado para retornar valores de contas e armazenamento juntamente com suas provas de Merkle.

A EIP-1186 define eth_getProof como um método que retorna valores de conta e valores de armazenamento de uma conta especificada com dados de prova.

A prova pode incluir dados accountProof que seguem o caminho a partir da raiz de estado.

A prova também pode incluir dados storageProof que seguem o caminho a partir de uma raiz de armazenamento de contrato.

Esse método é útil quando um aplicativo deseja evidências, e não apenas uma resposta RPC bruta.

Por exemplo, uma carteira ou bridge pode querer verificar um slot de armazenamento em relação à raiz de estado de um bloco.

Uma simples consulta de saldo apenas informa um valor.

Uma consulta de prova informa o valor e os dados criptográficos necessários para verificá-lo.

Essa distinção é importante porque provedores RPC podem estar errados, sofrer censura, ter bugs ou agir de forma maliciosa.

As provas de Merkle permitem que os usuários reduzam a confiança no provedor verificando a prova contra um cabeçalho de bloco confiável.

Trie de estado e nós completos

Nós completos precisam do estado atual para verificar novos blocos e transações.

A documentação oficial de nós de arquivo da Ethereum explica que os dados globais de cada conta e contrato são armazenados em um banco de dados de trie chamado estado.

Um nó completo acompanha o estado mais recente da rede para poder validar blocos e transações recebidos.

Normalmente, nós completos não mantêm todos os estados históricos para sempre.

Eles podem manter o estado mais recente e dados de estado recentes suficientes para lidar com reorganizações da cadeia e a operação normal da rede.

Estados históricos mais antigos geralmente podem ser podados, pois não são necessários para a verificação padrão da ponta mais recente da cadeia.

Por isso, consultar saldos antigos ou armazenamento de contrato antigo pode ser difícil em um nó completo normal.

O estado atual é necessário para a operação da rede.

Todos os estados intermediários históricos são úteis para análises e provas, mas exigem muito mais armazenamento.

Assim, a trie de estado afeta o hardware dos nós, a sincronização, o armazenamento e a descentralização.

Trie de estado e nós de arquivo

Um nó de arquivo armazena estados históricos, em vez de manter apenas o estado atual e estados recentes.

A documentação de nós de arquivo da Ethereum explica que nós de arquivo armazenam todos os estados históricos criados após cada bloco, trocando maiores exigências de disco por consultas históricas rápidas.

Isso é importante para exploradores de blockchain, auditores, pesquisadores, equipes de segurança, ferramentas fiscais, provedores de análise e desenvolvedores de dApps.

Por exemplo, um usuário pode perguntar qual era o saldo de uma conta em um bloco de vários anos atrás.

Um nó completo pode precisar reexecutar transações históricas para reconstruir esse estado.

Um nó de arquivo geralmente pode acessar o estado histórico diretamente no disco.

Essa velocidade tem o custo de requisitos de armazenamento muito maiores.

Portanto, o histórico da trie de estado é valioso, mas caro.

É por isso que muitos usuários dependem de provedores de infraestrutura para consultas de estados históricos.

No entanto, depender de um provedor pode acrescentar riscos de confiança, disponibilidade e censura.

Trie de estado e contratos inteligentes

Os contratos inteligentes dependem fortemente da trie de estado e das tries de armazenamento.

O objeto de conta de um contrato aparece na trie de estado global.

O código do contrato é comprometido por meio do codeHash.

O armazenamento persistente do contrato é comprometido por meio do storageRoot.

Quando um contrato inteligente é executado, ele pode ler e gravar slots de armazenamento.

Essas alterações atualizam a trie de armazenamento do contrato.

O novo storageRoot do contrato atualiza o objeto de conta na trie de estado global.

O objeto de conta atualizado altera a raiz de estado global.

Isso significa que até uma pequena atualização no armazenamento de um contrato pode alterar a raiz de estado final de um bloco.

Assim, a trie de estado faz parte de como os resultados de contratos inteligentes se tornam visíveis ao consenso.

Trie de estado e saldos de tokens

Muitos saldos de tokens são armazenados no armazenamento de contratos inteligentes, e não diretamente na trie de estado global.

Por exemplo, um contrato de token fungível pode armazenar um mapeamento de endereços de usuários para saldos de tokens.

Esse mapeamento fica na trie de armazenamento do contrato de token.

A trie de estado global armazena o objeto de conta do contrato de token, incluindo o storageRoot desse contrato.

Isso significa que o saldo de uma moeda nativa e o saldo de um token são armazenados de formas diferentes.

O saldo de uma moeda nativa faz parte de um objeto de conta na trie de estado global.

O saldo de um token geralmente é um valor de armazenamento na trie de armazenamento de um contrato de token específico.

Essa distinção é importante para provas e auditorias.

Para comprovar um saldo de moeda nativa, a prova da conta geralmente é suficiente.

Para comprovar um saldo de token, uma prova pode exigir tanto a prova de conta do contrato de token quanto a prova de armazenamento para o slot de saldo relevante.

Trie de estado e clientes leves

Clientes leves são clientes que verificam dados de blockchain sem armazenar todo o estado.

Uma trie de estado ajuda clientes leves porque permite provas compactas vinculadas a cabeçalhos de blocos.

Um cliente leve pode confiar ou verificar um cabeçalho de bloco e, então, usar provas de Merkle para conferir valores específicos do estado.

Isso é muito mais barato do que armazenar localmente todo o estado.

Por exemplo, uma carteira móvel pode querer verificar que um valor de armazenamento de contrato existe sem executar um nó completo de execução.

Uma bridge pode querer verificar que um evento de saque ou estado de conta foi incluído no estado de outra cadeia.

A trie de estado fornece a estrutura autenticada necessária para esses fluxos de trabalho.

No entanto, os tamanhos das provas e os custos de geração de provas ainda podem ser significativos.

Esse é um dos motivos pelos quais pesquisadores da Ethereum exploraram alternativas como árvores Verkle.

O objetivo é tornar a verificação de estado mais leve e escalável ao longo do tempo.

Trie de estado e clientes sem estado

Clientes sem estado são uma ideia de escalabilidade de blockchain de longo prazo, na qual validadores ou usuários podem verificar blocos sem armazenar todo o estado localmente.

Em vez de cada validador armazenar todo o estado, blocos ou transações incluiriam testemunhas que comprovam o estado que acessam.

A trie de estado é relevante porque as testemunhas da Merkle Patricia Trie atual podem ser grandes.

Testemunhas grandes podem tornar a verificação sem estado ineficiente.

O artigo da Ethereum Foundation sobre a estrutura de árvores Verkle explica que árvores Verkle funcionam de modo semelhante às árvores de Merkle, mas podem produzir testemunhas muito menores por meio de compromissos vetoriais.

Por isso, as árvores Verkle foram pesquisadas como um possível substituto da estrutura de compromisso de estado atual da Ethereum.

A trie de estado atual é segura e amplamente testada em produção, mas não foi projetada para produzir as menores testemunhas sem estado possíveis.

A pesquisa sobre ausência de estado busca, em parte, reduzir a carga que a trie de estado impõe aos nós.

Para os usuários, a conclusão prática é que o design da estrutura de dados de estado afeta a escalabilidade futura.

Para desenvolvedores, isso significa que os padrões de acesso ao estado e os sistemas de provas podem evoluir à medida que a pesquisa de protocolo avançar.

Trie de estado e árvores Verkle

Uma árvore Verkle é uma estrutura proposta de compromisso de estado que usa compromissos vetoriais, em vez de apenas links de hash.

O Ethereum.org afirma que a Ethereum planeja migrar futuramente para uma estrutura de árvore Verkle, embora cronogramas de protocolo e detalhes de implementação possam mudar.

As árvores Verkle são projetadas para tornar as provas menores do que as provas da Merkle Patricia Trie.

O artigo da Ethereum Foundation explica que os designs de árvores Verkle também unem tries de contas e de armazenamento em um layout diferente.

Essa seria uma grande mudança, pois atualmente a Ethereum usa uma trie de estado global e tries de armazenamento por conta.

Um modelo de estado baseado em Verkle poderia tornar os clientes sem estado mais práticos.

No entanto, migrar de uma trie de estado usada há muito tempo para uma nova estrutura de compromisso é complexo.

Isso afeta clientes, provas, carteiras, nós, regras de execução, layout de armazenamento e premissas dos desenvolvedores.

Portanto, a trie de estado é tanto a base atual quanto uma importante área de pesquisa contínua de protocolo.

Entender a trie de estado ajuda os usuários a compreender por que a pesquisa sobre Verkle é importante.

Trie de estado e inchaço de estado

Inchaço de estado significa que o estado ativo da blockchain fica maior e mais difícil de manter.

A trie de estado cresce quando mais contas, contratos, slots de armazenamento e dados de aplicativos permanecem ativos.

Um estado grande aumenta o uso de disco, o tempo de sincronização, a carga do banco de dados e os requisitos de hardware.

Se os nós se tornarem caros demais para operar, menos usuários poderão verificar a rede de forma independente.

Isso pode enfraquecer a descentralização.

O inchaço de estado é diferente do crescimento do histórico da blockchain porque o estado ativo é necessário para processar novas transações.

As transações históricas são importantes, mas estados intermediários antigos podem, às vezes, ser podados ou regenerados.

O estado atual precisa estar disponível para validação.

Isso faz do crescimento de estado um dos mais difíceis problemas de escalabilidade para blockchains de contratos inteligentes.

A trie de estado é a estrutura de dados em que esse crescimento se torna visível aos clientes.

Trie de estado e custos de gas

Os custos de gas são parcialmente projetados para precificar a computação e o acesso ao estado.

Gravar armazenamento persistente é caro porque aumenta ou altera o estado que os nós precisam manter.

Ler o estado também pode gerar custos, pois o acesso ao estado afeta o desempenho da execução.

Quando um contrato inteligente cria novo armazenamento, a trie de armazenamento e a raiz de estado global podem precisar ser atualizadas.

Quando um contrato inteligente exclui armazenamento, as regras de gas podem fornecer reembolsos ou incentivos, dependendo das regras atuais do protocolo.

Esses mecanismos de gas estão relacionados à trie de estado porque o estado persistente é um recurso compartilhado da rede.

Se gravações de armazenamento fossem muito baratas, os aplicativos poderiam inchar a trie de estado com dados de baixo valor.

Se gravações de armazenamento fossem caras demais, aplicativos úteis poderiam se tornar mais difíceis de desenvolver.

Os projetistas do protocolo precisam equilibrar usabilidade, segurança e sustentabilidade do estado.

A trie de estado fica no centro dessa troca econômica.

Trie de estado e provedores RPC

Provedores RPC expõem métodos que permitem que carteiras e aplicativos leiam o estado da blockchain.

Métodos de estado comuns incluem consultas de saldo, armazenamento, código, contagem de transações e chamadas de contrato.

A documentação oficial do JSON-RPC da Ethereum descreve métodos de estado como métodos que informam dados armazenados atualmente, como saldos de conta, dados de contratos e estimativas de gas.

Quando uma carteira solicita o saldo de uma conta, o provedor RPC lê dados de estado de um nó.

Quando um dApp solicita um valor de contrato, o provedor RPC pode ler um slot de armazenamento ou simular uma chamada em relação ao estado atual.

Frequentemente, os usuários dependem de provedores RPC sem pensar na trie de estado por trás da resposta.

No entanto, é a trie de estado que permite que esses valores façam parte de um estado de blockchain verificável.

Para aplicativos que exigem alto grau de confiança, respostas RPC brutas podem não ser suficientes.

Provas de estado podem oferecer maior garantia quando suportadas e verificadas corretamente.

Isso é importante para bridges, auditorias, ferramentas de conformidade e sistemas cross-chain.

Trie de estado e exploradores de blockchain

Exploradores de blockchain usam dados de estado para mostrar saldos, holdings de tokens, armazenamento de contratos, efeitos de transações e informações históricas de contas.

Exploradores frequentemente dependem de dados indexados, e não apenas de consultas diretas à trie de estado.

A indexação torna as buscas mais rápidas e as interfaces de usuário mais fáceis de criar.

No entanto, os dados indexados derivam, em última análise, do estado da blockchain, das transações, dos logs, dos recibos e dos resultados de execução.

Se um explorador exibe o saldo de uma conta em um bloco específico, essa informação está vinculada ao estado daquele bloco.

Se um explorador mostra saldos de tokens, geralmente os deriva de alterações no armazenamento de contratos e eventos.

Nós de arquivo podem ajudar exploradores a responder rapidamente perguntas sobre estados históricos.

Sem acesso ao estado histórico, um explorador pode precisar reconstruir estados antigos a partir do histórico de transações.

A trie de estado normalmente não é visível para usuários comuns de exploradores.

Ainda assim, é uma das estruturas centrais que tornam os dados dos exploradores verificáveis no nível do protocolo.

Trie de estado e bridges

Bridges frequentemente precisam verificar estados ou eventos de outro ambiente de blockchain.

Tries de estado e provas de Merkle podem apoiar essa verificação.

Por exemplo, uma bridge pode precisar de uma prova de que uma mensagem, valor de armazenamento ou estado de conta existia em determinado bloco.

Se a bridge puder confiar no cabeçalho do bloco e verificar a prova, poderá reduzir a dependência de um provedor centralizado de dados.

É por isso que a EIP-1186 observa que provas de Merkle são importantes para tecnologias Layer 2.

Provas de estado podem ajudar sistemas a verificar afirmações sobre saldos, slots de armazenamento e estado de contratos.

No entanto, a segurança de uma bridge depende de muito mais do que a estrutura de provas.

Ela também depende da verificação de cabeçalhos, premissas de finalidade, provas de fraude, provas de validade, controles multisig, segurança de contratos inteligentes e design operacional.

Uma prova correta da trie de estado é poderosa, mas é apenas uma parte da segurança de uma bridge.

Os usuários não devem presumir que uma bridge é segura apenas porque menciona provas de Merkle.

Trie de estado e redes Layer 2

Redes Layer 2 frequentemente usam raízes de estado, provas e estruturas de compromisso para resumir a execução off-chain ou em cadeias separadas.

Uma Layer 2 pode publicar raízes de estado em uma cadeia Layer 1.

Ela pode usar provas de fraude, provas de validade ou mecanismos de disponibilidade de dados para comprovar que suas transições de estado são válidas.

O design exato depende da arquitetura da Layer 2.

A trie de estado da Ethereum é um contexto importante porque mostra como uma blockchain pode se comprometer com um grande estado por meio de raízes compactas.

Sistemas Layer 2 podem usar estruturas de dados diferentes, mas o conceito é semelhante.

Um grande estado de execução é resumido por um compromisso.

Usuários e contratos verificam afirmações em relação a esse compromisso.

Esse é um dos motivos pelos quais tries de estado não são apenas um assunto de baixo nível para clientes.

Elas também fazem parte da escalabilidade, do design de rollups e da verificação cross-chain.

Trie de estado e segurança

A trie de estado melhora a segurança ao tornar detectável a adulteração do estado.

Se um nó alterar o saldo de uma conta sem seguir regras válidas de transação, a raiz de estado resultante não corresponderá ao cabeçalho de bloco aceito.

Se um provedor mentir sobre um valor de armazenamento, uma prova de Merkle válida deverá falhar em relação à raiz de estado confiável.

Se dois clientes discordarem sobre regras de transição de estado, poderão calcular raízes de estado diferentes e rejeitar os blocos um do outro.

Isso torna a trie de estado crítica para o consenso.

Bugs na implementação da trie de estado podem ser graves, pois podem causar divergência entre clientes ou verificação incorreta do estado.

Por isso, clientes de execução devem implementar cuidadosamente a lógica de trie, codificação, hashing e atualizações de estado.

A segurança da trie de estado também depende da resistência criptográfica a colisões de hash.

Se atacantes pudessem criar dois estados diferentes com a mesma raiz, poderiam comprometer a integridade das provas.

As tries de estado de blockchains modernas dependem de premissas criptográficas que tornam isso praticamente inviável nas condições atuais.

Trie de estado e implementações de clientes

Diferentes clientes de execução da Ethereum implementam as mesmas regras de estado, mas podem usar bancos de dados internos e otimizações diferentes.

O resultado crítico para o consenso deve ser a mesma raiz de estado.

A forma como um cliente armazena nós da trie em disco pode variar.

A forma como um cliente mantém o estado em cache pode variar.

A forma como um cliente poda estados antigos pode variar.

A forma como um cliente atende consultas históricas pode variar.

Isso significa que a trie de estado é tanto um conceito de protocolo quanto um desafio de implementação.

No nível do protocolo, os clientes devem concordar sobre a raiz e as regras de transição.

No nível do banco de dados, as equipes de clientes podem otimizar layout de armazenamento, velocidade de acesso, poda, snapshots e comportamento de sincronização.

Os usuários geralmente percebem essas diferenças como desempenho dos nós, uso de disco, tempo de sincronização e confiabilidade de RPC.

Trie de estado e depuração para desenvolvedores

Desenvolvedores frequentemente encontram a trie de estado indiretamente por meio de slots de armazenamento, provas de conta e consultas de estado histórico.

Um desenvolvedor de contrato inteligente pode precisar saber como os mapeamentos são armazenados no armazenamento de contratos.

Um pesquisador de segurança pode precisar comprovar que um slot de armazenamento tinha um valor específico em um bloco.

Um desenvolvedor de bridge pode precisar verificar o valor de estado de um contrato em outro ambiente.

Um desenvolvedor de carteira pode precisar explicar por que uma consulta de saldo depende de uma tag de bloco como latest ou finalized.

Um desenvolvedor de dApp pode precisar de um nó de arquivo ao depurar estados antigos de contratos.

Entender a trie de estado ajuda desenvolvedores a interpretar corretamente esses problemas.

Também ajuda a evitar a confusão entre histórico de transações e estado atual.

Muitos bugs decorrem da suposição de que eventos, armazenamento, saldos e estado de conta são a mesma coisa.

A trie de estado esclarece onde cada informação é armazenada.

Trie de estado e experiência comum do usuário

A maioria dos usuários de cripto nunca interage diretamente com uma trie de estado.

Eles interagem com carteiras, dApps, exploradores e provedores RPC.

Quando uma carteira mostra um saldo, ela está lendo o estado.

Quando um dApp verifica se um usuário aprovou um token, ele está lendo o estado de armazenamento do contrato.

Quando uma chamada de contrato inteligente é bem-sucedida ou falha, ela depende do estado atual.

Quando um explorador mostra o valor de um contrato em um bloco, ele depende de acesso ao estado ou de dados indexados derivados do estado.

A trie de estado é uma infraestrutura oculta, mas afeta a atividade normal dos usuários todos os dias.

Se o acesso ao estado for lento, os dApps podem parecer lentos.

Se um provedor RPC fornecer um estado incorreto, os usuários poderão ver saldos errados ou transações que falharam.

Se o estado histórico não estiver disponível, os usuários podem ter dificuldade para auditar atividades antigas.

Equívocos comuns sobre a trie de estado

Um equívoco comum é pensar que a trie de estado armazena todas as transações.

A trie de estado armazena o estado atual das contas, enquanto as transações são armazenadas separadamente em blocos e tries de transações.

Outro equívoco é pensar que o armazenamento de contratos inteligentes é guardado diretamente na trie de estado global.

A trie de estado global armazena objetos de conta, e o armazenamento de contratos fica em tries de armazenamento separadas, referenciadas pelos valores storageRoot.

Um terceiro equívoco é pensar que um nó completo sempre armazena todos os estados históricos.

Muitos nós completos mantêm o estado atual e recente enquanto podam estados intermediários antigos.

Um quarto equívoco é pensar que uma raiz de estado é o próprio estado.

Uma raiz de estado é um compromisso criptográfico compacto com o estado, não o banco de dados de estado completo.

Um quinto equívoco é pensar que uma prova de Merkle comprova todos os fatos possíveis sobre um contrato.

Uma prova de Merkle comprova um valor específico de conta ou armazenamento em relação a uma raiz específica, não o significado comercial completo desse valor.

Benefícios da trie de estado

O primeiro benefício da trie de estado é a verificabilidade.

Usuários e clientes podem verificar valores de estado por meio de provas vinculadas a uma raiz de estado.

O segundo benefício é o determinismo.

Clientes que processam o mesmo bloco válido devem chegar à mesma raiz de estado.

O terceiro benefício é a busca eficiente.

Os caminhos da trie permitem que clientes encontrem dados de conta e armazenamento por meio de chaves determinísticas.

O quarto benefício é a evidência de adulteração.

Alterar um valor muda o caminho de hashes e a raiz final.

O quinto benefício é o suporte a clientes leves.

Provas seletivas podem verificar dados sem baixar todo o estado.

O sexto benefício é uma estrutura clara de transição de estado.

Cada bloco transforma o estado anterior em um novo estado com uma nova raiz.

Esses benefícios tornam a trie de estado uma base das blockchains de contratos inteligentes baseadas em contas.

Limitações da trie de estado

A primeira limitação é o crescimento do armazenamento.

À medida que mais contas e valores de armazenamento de contratos se acumulam, o estado se torna mais pesado para os nós.

A segunda limitação é o tamanho das provas.

Provas da Merkle Patricia Trie podem ser maiores do que o desejado para clientes sem estado e verificação em grande escala.

A terceira limitação é a complexidade de implementação.

Codificação de tries, hashing, poda, cache e armazenamento em banco de dados são difíceis de implementar corretamente.

A quarta limitação é o custo do estado histórico.

Manter todos os estados históricos exige muito mais espaço em disco do que a operação normal de um nó completo.

A quinta limitação é a confusão entre desenvolvedores.

Muitos desenvolvedores não entendem a diferença entre estado, armazenamento, transações, recibos, logs e dados indexados.

Essas limitações explicam por que a gestão de estado continua sendo uma área ativa de pesquisa e engenharia.

A trie de estado funciona, mas cria desafios reais de escalabilidade e usabilidade.

Boas práticas para desenvolvedores

Entenda a diferença entre estado de conta e armazenamento de contrato antes de desenvolver sistemas baseados em provas.

Use a documentação oficial da Ethereum ao aprender sobre a mecânica da Merkle Patricia Trie.

Use eth_getProof com cuidado ao desenvolver sistemas que exigem provas de conta ou armazenamento.

Verifique as provas em relação a cabeçalhos de blocos confiáveis, em vez de confiar cegamente em respostas RPC.

Lembre-se de que saldos de tokens geralmente ficam no armazenamento de contratos, não diretamente na trie de estado global.

Use nós de arquivo ou provedores de dados de arquivo quando precisar de acesso rápido a estados históricos antigos.

Projete contratos inteligentes para minimizar armazenamento persistente desnecessário.

Considere os custos de gas ao gravar em armazenamento, pois o estado persistente é caro.

Acompanhe pesquisas de protocolo, como árvores Verkle, se seu sistema depende fortemente de provas de estado.

Não presuma que o formato atual das provas permanecerá inalterado para sempre em futuras atualizações de protocolo.

Boas práticas para usuários

Use carteiras e exploradores confiáveis, mas lembre-se de que suas exibições vêm de consultas de estado e dados indexados.

Verifique os números dos blocos ao comparar saldos ou valores de contratos entre ferramentas diferentes.

Entenda que saldo atual e saldo histórico podem exigir acessos a dados diferentes.

Use verificação baseada em provas quando for necessário um alto grau de garantia e a ferramenta oferecer suporte.

Não presuma que uma resposta RPC simples é o mesmo que uma prova criptográfica.

Tenha cuidado ao usar bridges ou aplicativos que afirmam verificar o estado de outra cadeia.

Verifique se um aplicativo usa estado atual, estado histórico, logs ou indexação off-chain.

Entenda que alterações no armazenamento de contratos inteligentes podem afetar o comportamento do aplicativo mesmo quando transferências de tokens não são evidentes.

Lembre-se de que a transparência da blockchain depende de estruturas de dados como a trie de estado.

A trie de estado é invisível para a maioria dos usuários, mas ajuda a tornar verificáveis os dados de cadeias públicas.

FAQ

O que significa state trie?

Uma trie de estado é uma árvore criptográfica de chave-valor que armazena o estado atual da blockchain e produz um hash raiz que se compromete com esse estado.

O que é a trie de estado da Ethereum?

A trie de estado da Ethereum é a Merkle Patricia Trie modificada global que mapeia endereços de contas com hash para objetos de conta codificados em RLP.

O que é armazenado em um objeto de conta Ethereum?

Um objeto de conta Ethereum contém nonce, balance, storageRoot e codeHash.

O que é uma raiz de estado?

Uma raiz de estado é o hash raiz da trie de estado após a execução das transações de um bloco.

A trie de estado é igual à trie de armazenamento?

Não. A trie de estado armazena objetos de conta, enquanto tries de armazenamento guardam o armazenamento de contratos de contas individuais de contrato.

A trie de estado é igual ao histórico de transações?

Não. A trie de estado armazena o estado atual das contas, enquanto o histórico de transações registra as transações ordenadas incluídas nos blocos.

O que é uma prova de Merkle?

Uma prova de Merkle é um conjunto de nós da trie que pode comprovar que um valor específico está incluído no estado comprometido por um hash raiz.

O que é eth_getProof?

eth_getProof é um método JSON-RPC da Ethereum que retorna valores de contas e armazenamento com dados de prova de Merkle.

Por que nós de arquivo são importantes para a trie de estado?

Nós de arquivo são importantes porque armazenam estados históricos e podem responder consultas de estados antigos mais rapidamente do que nós completos normais.

A Ethereum sempre usará a trie de estado atual?

A Ethereum usa atualmente Merkle Patricia Tries em sua camada de execução, mas a pesquisa da Ethereum explorou árvores Verkle como uma futura estrutura de compromisso de estado.

Conclusão

Uma trie de estado é uma das principais estruturas de dados por trás das blockchains de contratos inteligentes baseadas em contas.

Ela armazena o estado atual das contas e permite que os clientes resumam esse estado por meio de uma única raiz criptográfica.

Na Ethereum, a trie de estado global mapeia endereços de contas com hash para objetos de conta que contêm nonce, balance, storageRoot e codeHash.

Cada contrato pode então ter sua própria trie de armazenamento, cuja raiz fica armazenada dentro do objeto de conta do contrato.

A raiz de estado no cabeçalho de cada bloco se compromete com o estado resultante completo após o processamento de todas as transações desse bloco.

Isso torna a trie de estado essencial para consenso, verificação, clientes leves, provas, sincronização de nós, execução de contratos inteligentes e integridade dos dados da blockchain.

As tries de estado também criam desafios, pois o crescimento do estado ativo aumenta o armazenamento dos nós, o tamanho das provas, a complexidade de sincronização e os custos de dados históricos.

Esses desafios explicam por que nós de arquivo, poda de estado, custos de gas, design de armazenamento, eth_getProof e pesquisas sobre árvores Verkle estão todos ligados ao mesmo tema.

Para usuários, a trie de estado fica em grande parte oculta por trás de carteiras, exploradores e dApps.

Para desenvolvedores e equipes de infraestrutura, a trie de estado é um conceito essencial para entender saldos, armazenamento de contratos, provas, consultas históricas e limites de escalabilidade.

No contexto do glossário cripto, State Trie significa o banco de dados autenticado do estado da blockchain que registra o estado atual das contas e produz a raiz de estado usada para verificar esse estado.

A principal conclusão é que a trie de estado transforma um estado de blockchain enorme e em constante mudança em uma estrutura verificável, na qual nós, aplicativos e usuários podem confiar por meio de raízes e provas criptográficas.