
Uma Merkle tree é uma estrutura de dados hierárquica que agrega grandes volumes de informação num único “root hash”. Esta arquitetura permite verificar se um dado específico está incluído num conjunto de dados sem necessidade de descarregar toda a informação.
Um hash funciona como uma “impressão digital”: ao processar qualquer entrada por um algoritmo criptográfico (como SHA‑256, utilizado no Bitcoin), obtém-se uma cadeia de comprimento fixo. A mesma entrada gera sempre o mesmo resultado, enquanto uma alteração mínima origina um hash totalmente diferente. Numa Merkle tree, cada elemento de dados é convertido em hash para formar as “folhas” da árvore. Pares de hashes das folhas são combinados e novamente convertidos em hash para criar os “nós-pai”. Este processo repete-se camada a camada até ser gerado o “root hash” superior, também conhecido como Merkle root.
Uma Merkle tree opera ao combinar e converter em hash, repetidamente, os hashes adjacentes de baixo para cima, produzindo no final um root hash único que representa o compromisso com o conjunto de dados.
Por exemplo, considere quatro transações: TxA, TxB, TxC e TxD.
Se existir um número ímpar de folhas, normalmente a última é duplicada ou aplica-se uma regra de preenchimento para assegurar o emparelhamento em todas as camadas. A principal vantagem reside no facto de, enquanto a função de hash for segura, qualquer alteração nos dados subjacentes refletir-se no root hash, tornando praticamente impossível falsificar dados.
Os principais casos de utilização das Merkle trees são a verificação eficiente de inclusão e a sincronização leve, tornando-as ideais para gerir conjuntos de dados massivos.
Em cenários de light client, basta ao utilizador obter o root hash do cabeçalho do bloco e um pequeno número de “branch hashes” (Merkle proofs) para confirmar a inclusão de um dado específico. Uma Merkle proof funciona como as “peças do puzzle” ao longo do caminho da folha até à raiz — permitindo reconstruir o root hash camada a camada apenas com um subconjunto de hashes.
Em soluções de cross-chain e Rollups, as Merkle trees permitem agrupar lotes de transações ou alterações de estado. A cadeia principal armazena só o root hash, poupando espaço e facilitando a validação.
Para proof-of-reserves em exchanges, as Merkle trees convertem em hash cada registo de ativos de utilizador como folha, agregando-os num root hash público. Por exemplo, a Gate disponibiliza aos utilizadores o root hash e o hash da sua entrada anónima, juntamente com os branch hashes. Isto permite aos utilizadores verificar autonomamente que os seus ativos foram incluídos no total — devendo considerar também o momento do snapshot e o âmbito da auditoria.
Em dezembro de 2025, as Merkle trees e as suas variantes continuam a ser estruturas essenciais nas principais blockchains públicas e redes de layer 2, graças aos baixos custos de verificação e à facilidade de implementação.
No Bitcoin, cada cabeçalho de bloco regista a Merkle root de todas as transações incluídas nesse bloco.
Os light clients descarregam apenas os cabeçalhos dos blocos (cerca de 80 bytes cada) em vez de todos os dados de transação. Para verificar se um pagamento existe num bloco específico, a rede fornece uma Merkle proof (uma série de branch hashes para essa transação). O light client calcula iterativamente os hashes desde a transação até aos branches; se o resultado corresponder à Merkle root do cabeçalho, confirma-se que “esta transação está incluída neste bloco”.
Este processo denomina-se SPV (Simplified Payment Verification). A principal vantagem é a exigência extremamente reduzida de largura de banda e armazenamento — ideal para dispositivos móveis ou integrados. Contudo, o SPV apenas verifica a inclusão; não garante contra double-spending nem confirma a estabilidade da cadeia. Os utilizadores devem considerar as confirmações de bloco e a segurança da rede.
O Ethereum utiliza uma variante da Merkle tree para manter o estado de contas e contratos; a estrutura típica é a “Merkle Patricia Tree”, que acrescenta compressão de prefixos e armazenamento ordenado de pares chave-valor para pesquisas e atualizações eficientes.
Nos Rollups, operadores agrupam lotes de transações ou saldos de utilizadores numa Merkle tree e submetem periodicamente o root hash à cadeia principal. Este mecanismo — “state commitment” — implica que, embora os dados detalhados não estejam on-chain, qualquer pessoa pode usar uma Merkle proof para verificar se um saldo ou transação específica está incluído no lote. Muitos zk-Rollups utilizam funções de hash otimizadas para circuitos (como Poseidon), mas o princípio de verificação mantém-se.
Em dezembro de 2025, a maioria das soluções layer 2 de referência continua a utilizar Merkle roots para provas de estado em lote, combinando-as com soluções de disponibilidade de dados — publicando os dados brutos on-chain ou em camadas dedicadas — para garantir que qualquer pessoa possa reconstruir e verificar alterações de estado.
A verificação de uma Merkle proof consiste em partir do hash da folha e combiná-lo sequencialmente com os branch hashes fornecidos, até atingir o root hash conhecido.
Passo 1: Reunir os materiais. É necessário: (1) O hash dos dados a verificar (hash da folha); (2) uma lista ordenada de branch hashes; (3) o root hash de destino. A informação de direção (esquerda/direita) indica como concatenar os hashes em cada etapa.
Passo 2: Começar pela folha. De acordo com a direção em cada nível, concatenar o hash da folha com o respetivo branch hash pela ordem indicada e convertê-los em hash para obter o nó-pai.
Passo 3: Repetir. Continuar este processo com os branch hashes seguintes até obter o resultado final.
Passo 4: Comparar com o root hash. Se o resultado final corresponder ao root hash publicado, prova-se que os dados estão incluídos no lote; caso contrário, a prova é inválida.
Por exemplo, na implementação de proof-of-reserves da Gate, os utilizadores recebem o hash da sua entrada anónima, os branch hashes relevantes e o root hash. Seguindo estes passos localmente, confirma-se “os meus ativos estão incluídos”, mas isto não significa que os fundos estejam já on-chain ou imediatamente disponíveis para levantamento — a gestão de fundos da plataforma e os relatórios de auditoria devem sempre ser avaliados.
As Merkle trees dependem da segurança dos algoritmos de hash subjacentes. Hashes modernos como SHA‑256 e Keccak são considerados seguros atualmente, mas podem ser comprometidos no futuro; os algoritmos devem ser atualizados conforme o consenso do setor.
As Merkle trees apenas garantem a verificação de inclusão — não asseguram correção ou completude dos dados. Por exemplo, a proof-of-reserves mostra apenas que uma entrada está incluída; não impede double-counting nem garante divulgação total de passivos. Auditorias externas, fluxos de fundos on-chain e janelas temporais devem ser utilizados em conjunto para uma avaliação rigorosa.
Os custos de atualização e o design da árvore também são relevantes. Conjuntos de dados que mudam rapidamente exigem variantes eficientes e estratégias de armazenamento; caso contrário, as atualizações podem levar a recomputações excessivas. Erros de implementação (como ordem incorreta ou concatenação inconsistente) podem causar falhas de verificação ou vulnerabilidades.
A disponibilidade dos dados representa outro risco. Se os dados originais não forem publicados ou não estiverem acessíveis, mesmo com reconstrução do root hash e auditoria, a validação torna-se difícil. Os Rollups mitigam este risco ao publicar os dados em lote on-chain ou em camadas especializadas, aumentando a transparência.
O conceito central das Merkle trees é “usar hashes como impressões digitais e agregação hierárquica” — comprimindo grandes conjuntos de dados num root hash, permitindo a qualquer pessoa verificar a inclusão utilizando apenas alguns branch hashes. São a base do modelo SPV do Bitcoin, da gestão de estado do Ethereum, dos compromissos de estado em Rollups e dos sistemas de proof-of-reserves das exchanges. Para compreensão prática: comece por construir uma Merkle tree simples com oito folhas e calcule manualmente a raiz; observe Merkle roots reais de blocos Bitcoin em exploradores; por fim, experimente a verificação local usando os materiais de proof-of-reserves da Gate — ligando progressivamente teoria e prática.
As Merkle trees ligam dados através de múltiplas camadas de hashing — qualquer alteração em qualquer camada modifica inteiramente o root hash de topo. Os verificadores apenas comparam o root hash para detetar imediatamente adulterações. Este design permite às blockchains validar grandes volumes de transações com custos mínimos.
Uma light wallet não precisa de descarregar todos os dados de transação — apenas os cabeçalhos dos blocos e as Merkle roots são armazenados localmente. Quando pretende verificar a sua transação, a wallet solicita um “Merkle proof” (o caminho desde a sua transação até à raiz) aos full nodes. Com apenas alguns passos de hashing, a wallet confirma a inclusão — permitindo verificação rápida mesmo em dispositivos móveis sem sincronizar gigabytes de dados da blockchain.
As soluções Rollup utilizam Merkle trees para comprimir milhares de transações de Layer 2 num único root hash submetido à Ethereum mainnet. A mainnet só precisa de validar este root para confirmar todas as transações subjacentes — reduzindo drasticamente os custos on-chain. Os utilizadores beneficiam de transações rápidas em Layer 2, mantendo as garantias de segurança da mainnet.
Merkle roots idênticos significam que ambas as árvores contêm exatamente os mesmos dados organizados na mesma ordem. Esta propriedade é fundamental para as blockchains: se o seu conjunto de transações produz uma raiz igual à dos mineradores ou validadores, pode provar que viu uma lista de transações idêntica. Raízes diferentes indicam que os dados de alguém foram alterados.
O SPV suporta as light wallets no Bitcoin. A wallet descarrega apenas os cabeçalhos dos blocos (que incluem Merkle roots), não os conjuntos completos de transações. Para verificar transações, solicita um “Merkle path” aos mineradores — realizando hashing até confirmar se a transação está incluída nesse bloco. Isto permite verificação segura mesmo com armazenamento limitado no dispositivo.


