Fundamentos de blockchain: hashes, consenso, finalidade e trade-offs

Tire os gráficos de cotação e o vocabulário, e uma blockchain responde a uma pergunta estreita, mas genuinamente difícil: como um grupo de partes que não confiam umas nas outras, e que não podem contar com nenhuma autoridade única, consegue concordar sobre a mesma lista ordenada de fatos? A pesquisa em sistemas distribuídos estuda esse problema há décadas. A novidade de 2008 foi uma maneira de resolvê-lo em uma rede aberta, na qual qualquer um pode entrar, sair ou mentir, sem saber de antemão quem são os participantes.

Essa solução tem um custo real, e entender tanto o mecanismo quanto o custo é o que separa o julgamento de engenharia útil do entusiasmo. Este guia explica a engrenagem a partir das primitivas criptográficas, compara com honestidade as famílias de consenso e termina com os casos em que a resposta é "use um banco de dados". O lado programável — contratos, gas, tokens — continua em Ethereum e smart contracts.

O problema do acordo

Imagine um livro-razão compartilhado sem dono. Qualquer um pode propor lançamentos; alguns participantes estão offline, outros são maliciosos, e as mensagens chegam fora de ordem ou simplesmente não chegam. Mesmo assim, dois participantes honestos precisam terminar com um histórico idêntico — caso contrário, a mesma unidade de valor poderia ser gasta duas vezes, uma contra cada versão.

Protocolos clássicos resolvem isso entre um conjunto conhecido de participantes, tolerando que uma fração deles se comporte de forma arbitrária. A limitação está justamente na palavra "conhecido": em uma rede aberta, um atacante pode criar identidades sem limite e vencer qualquer votação. A sacada por trás das blockchains públicas é tornar a participação na decisão cara e mensurável — queimando eletricidade ou imobilizando capital —, de modo que a influência seja proporcional a um recurso escasso, e não ao número de nomes que você inventa.

Todo o resto decorre disso: a estrutura de blocos existe para tornar barato verificar o histórico, os incentivos existem para tornar o comportamento honesto mais lucrativo do que o ataque, e as características de desempenho são o preço pago pela participação aberta.

Os componentes criptográficos

Três primitivas fazem todo o trabalho pesado. Nenhuma é específica de blockchain; a combinação, sim.

Funções hash criptográficas mapeiam qualquer entrada para um digest de tamanho fixo, de forma determinística e irreversível, com a propriedade de que qualquer mudança na entrada produz uma saída completamente diferente.

sha256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
sha256("hellp") = fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7

Mudou uma letra e nenhum bit da saída tem relação com o anterior.
É o efeito avalanche, e é ele que faz do hash uma impressão digital
de um documento, de um bloco ou de um histórico inteiro que denuncia
qualquer adulteração.

Você pode testar isso com o gerador de hash, que roda no navegador: cole um parágrafo, troque uma vírgula e compare os digests.

Assinaturas digitais garantem autenticidade sem segredos compartilhados. Quem tem uma chave privada assina uma mensagem; qualquer pessoa com a chave pública correspondente consegue verificar a assinatura, mas não consegue forjar uma. Em uma blockchain, um endereço é derivado de uma chave pública, então "possuir" um ativo não significa nada além de ter a chave privada capaz de autorizar sua transferência. Não existe redefinição de senha. A custódia de chaves — hardware wallets, esquemas multiassinatura, assinaturas de limiar, custodiantes institucionais — é, portanto, toda a história de segurança para o usuário final, e as perdas vêm, em sua esmagadora maioria, de chaves perdidas, e não de falhas no protocolo.

Árvores de Merkle comprimem um conjunto de transações em um único digest, aplicando hash a pares de hashes, nível a nível, até chegar a uma raiz única.

        root = H( H12 || H34 )
        /                    \
  H12 = H(h1 || h2)     H34 = H(h3 || h4)
     /        \            /        \
   h1=H(tx1) h2=H(tx2)  h3=H(tx3) h4=H(tx4)

h(tx1) = 709b55bd3da0f5a838125bd0ee20c5bfdd7caba173912d4281cae816b79a201b
h(tx2) = 27ca64c092a959c7edc525ed45e845b1de6a7590d173fd2fad9133c8a779a1e3
H12    = bbea820f07f7f89aeea1ab4a354ecea39f2f72accd05c64371522ee371cd0c48

O ganho é a prova de Merkle: para provar que tx1 está em um bloco com um milhão de transações, basta fornecer h2, H34 e a raiz — um número logarítmico de hashes, em vez do bloco inteiro. Light clients, pontes entre cadeias e provas de fraude de rollups se apoiam nisso.

Blocos, cadeias e estado

Um bloco é um cabeçalho mais uma lista de transações. O cabeçalho contém o hash do cabeçalho do bloco anterior, a raiz de Merkle das transações, um timestamp e campos específicos do protocolo.

{
  "number": 21493087,
  "parentHash": "0x8f1c...a3d2",
  "transactionsRoot": "0xbbea...0c48",
  "stateRoot": "0x4d7e...91ab",
  "timestamp": 1757232000,
  "proposer": "0x2b9f...77c1"
}

Como cada cabeçalho carrega o hash do seu pai, alterar uma transação antiga muda a raiz de Merkle do bloco dela, portanto o hash do seu cabeçalho e, com isso, a referência ao pai de todos os blocos seguintes. A adulteração não é impedida — ela se torna evidente e cara, que é a forma honesta de descrever a imutabilidade.

Existem dois modelos contábeis. O modelo UTXO trata o valor como um conjunto de saídas não gastas discretas, cada uma consumida por inteiro e substituída por novas saídas; ele paraleliza bem a validação e mantém um grafo de auditoria limpo. O modelo de contas mantém um saldo por endereço e o altera, o que é muito mais natural para contratos programáveis. O modelo de contas precisa de um nonce explícito por remetente para impedir que uma transação assinada seja reenviada (replay).

As famílias de consenso comparadas

O consenso decide quem pode adicionar o próximo bloco e como as divergências se resolvem.

Na prova de trabalho, os proponentes procuram um cabeçalho cujo hash fique abaixo de um alvo. A busca é força bruta pura, a dificuldade se ajusta para que os blocos cheguem em ritmo constante, e reescrever o histórico exige superar em poder computacional o restante da rede. Sua segurança é fácil de analisar, e seu consumo de energia não é um detalhe de implementação: é o próprio mecanismo.

A prova de participação troca hardware por capital depositado. Os validadores bloqueiam fundos, são selecionados para propor e atestar, e perdem parte do stake — o slashing — por mau comportamento comprovável, como assinar dois blocos conflitantes. O Ethereum concluiu essa transição, reduzindo seu consumo de energia em ordens de grandeza sem abrir mão da participação aberta. O trade-off deixa de ser "energia é cara" e passa a ser "capital se concentra", e boa parte do esforço de design vai para desestimular essa concentração.

Protocolos tolerantes a falhas bizantinas da família clássica pressupõem um conjunto conhecido de membros e chegam a um acordo por meio de rodadas explícitas de votação, tolerando até cerca de um terço de participantes com falha. Eles oferecem finalidade imediata e alto throughput e são a escolha natural para redes permissionadas, mas o conjunto de membros precisa ser governado, o que é um problema político, e não técnico.

Pública, privada e permissionada

Uma rede pública sem permissão deixa qualquer um ler, transacionar e validar. Seu modelo de custo é um mercado de taxas, e sua premissa de confiança é "nenhuma coalizão majoritária do recurso escasso".

Uma rede permissionada admite organizações conhecidas, muitas vezes com canais ou grupos de privacidade para que cada participante veja apenas as transações que lhe dizem respeito. É aqui que ficam as plataformas de consórcio corporativo: a identidade é emitida por um serviço de associação, o consenso é BFT ou tolerante a falhas por parada (crash), o throughput é muito maior e a confidencialidade é alcançável.

Entre as duas, a pergunta honesta é sempre a mesma: quem é o adversário? Se os membros de um consórcio não têm motivo para fraudar uns aos outros e um operador neutro é aceitável, um banco de dados replicado com controle de acesso forte e logs de auditoria criptográficos entrega a maior parte do benefício com uma fração da complexidade. Muitos projetos de consórcio chegaram discretamente a essa conclusão.

Forks, finalidade e o problema da reorganização

Quando dois blocos válidos aparecem na mesma altura, a rede se bifurca temporariamente e depois converge seguindo a cadeia que o protocolo prefere. Os blocos deixados para trás ficam órfãos, e suas transações voltam para o pool. Isso é uma reorganização, um evento comum e esperado — e é por isso que as aplicações esperam confirmações antes de considerar um pagamento concluído. Na prova de participação com finalidade explícita, esperar o checkpoint finalizado é a garantia mais forte.

Mudanças deliberadas de protocolo também causam forks. Um soft fork torna as regras mais restritivas, de modo que nós antigos continuam aceitando os novos blocos; um hard fork as afrouxa ou altera, então todos os nós precisam se atualizar ou a rede se divide de forma permanente. Os dois são eventos de governança tanto quanto de engenharia.

A regra prática para quem constrói uma integração: nunca trate um evento on-chain como definitivo na primeira vez que o vir. Inscreva-se nos eventos de confirmação ou nos sinais de finalidade, torne seus handlers idempotentes e esteja pronto para reverter um efeito no nível da aplicação se uma reorganização remover a transação — a mesma disciplina de qualquer transação distribuída com compensações.

Escalabilidade, custo e layer 2

O trilema da escalabilidade resume a restrição: descentralização, segurança e escalabilidade — dá para ter duas com folga. Aumentar o throughput com blocos maiores encarece a operação de um nó, o que reduz o número de validadores independentes e, portanto, a descentralização.

A resposta dominante é a layer 2: executar as transações fora da cadeia principal e usá-la apenas para liquidação e disponibilidade de dados. Optimistic rollups publicam resultados em lote e abrem uma janela de contestação durante a qual uma prova de fraude pode derrubá-los. Zero-knowledge rollups publicam uma prova de validade sucinta, de modo que a correção é verificada matematicamente e os saques não precisam de período de contestação. Canais de pagamento permitem que duas partes transacionem de forma privada fora da cadeia e liquidem apenas o saldo final. Todos herdam a segurança da camada base enquanto levam a execução para outro lugar, e todos acrescentam o risco das pontes, que historicamente foi onde ocorreram as maiores perdas.

Vale deixar os custos claros: na camada base, as transações são medidas e precificadas pela demanda, o armazenamento é de longe o recurso mais caro e a latência de confirmação vai de segundos a minutos. Compare isso com os arranjos de pagamento instantâneo de fundamentos de sistemas de pagamento, que movimentam valores de varejo em menos de dez segundos a um custo marginal quase nulo, e fica claro que uma blockchain não compete em throughput nem em preço — ela só compete onde a ausência de um operador confiável é o requisito.

Quando uma blockchain é a resposta errada

Ser útil sobre essa tecnologia significa estar disposto a dizer não. Um livro-razão compartilhado é a ferramenta errada quando:

• Uma única organização controla os dados. Você reinventou um banco de dados com latência pior e sem DELETE.
• Os participantes já confiam em um intermediário. O intermediário sai mais barato.
• Você precisa de confidencialidade. Tudo o que está em uma cadeia pública fica visível para sempre; privacidade exige uma engrenagem extra considerável.
• Você precisa apagar ou corrigir registros. O direito à eliminação e os logs append-only estão fundamentalmente em tensão.
• Os dados se originam fora da cadeia. Nenhum mecanismo de consenso consegue verificar que uma remessa realmente chegou; esse é o problema do oráculo, e ele transfere a confiança para quem reporta a informação.
• Você precisa de milhares de transações por segundo com baixa latência. As camadas base não foram feitas para isso.

A lista complementar é curta, mas real: liquidação entre instituições sem um operador comum natural, atestações de procedência e integridade em que os dados de base ficam fora da cadeia, e infraestrutura financeira aberta e programável em que o acesso sem permissão é justamente o objetivo. Avalie uma proposta perguntando se remover a cadeia remove algo essencial — se a resposta honesta for que um log de auditoria assinado bastaria, construa o log de auditoria assinado.

Principais pontos

• Uma blockchain resolve o acordo entre participantes desconhecidos que desconfiam uns dos outros; é por essa garantia estreita que você paga em custo, em latência e em privacidade.
• O encadeamento de hashes e as árvores de Merkle tornam a adulteração evidente e as provas de inclusão baratas; as assinaturas digitais fazem da custódia de chaves todo o modelo de segurança dos usuários.
• A prova de trabalho compra segurança com energia, a prova de participação com capital em risco, e os protocolos BFT com um conjunto conhecido de membros e finalidade imediata.
• A finalidade é probabilística em algumas cadeias e explícita em outras — sempre espere as confirmações e projete handlers que sobrevivam a uma reorganização.
• O trilema empurra o throughput para fora da camada base, rumo a rollups e canais, que herdam sua segurança mas acrescentam o risco das pontes.
• Se uma única organização é dona dos dados, se é preciso apagar registros, se a confidencialidade importa ou se já existe um operador confiável, escolha um banco de dados e diga isso claramente.