Blocos e cabeçalhos como dados

Os blocos são a unidade em que uma blockchain registra tempo e ordem; portanto, toda linha do tempo, total diário e afirmação sobre o que aconteceu “antes ou depois” depende de lê-los corretamente. Os blocos também podem ser substituídos: a parte mais recente de qualquer cadeia é provisória. Saber o que um cabeçalho contém, até que ponto seu carimbo de data e hora é confiável e quando é seguro confiar em um bloco impede que dados provisórios apareçam em suas conclusões.

O que um cabeçalho contém

Um cabeçalho de bloco é um pequeno registro que resume o bloco e o vincula ao seu bloco pai. Um cabeçalho do Bitcoin tem exatamente 80 bytes e seis campos:

O hash do bloco não é um campo do cabeçalho: ele é o duplo SHA-256 dos 80 bytes do cabeçalho, e os exploradores o exibem na ordem inversa dos bytes, por isso ele começa com zeros. O getblock do Bitcoin Core adiciona valores derivados, como height, mediantime, chainwork e confirmations.

Um cabeçalho do Ethereum tem mais campos porque também registra compromissos com o estado e os recibos. Os campos mais usados pelos analistas:

Os campos aparecem somente a partir da atualização que os introduziu; portanto, um pipeline deve aceitar que estejam ausentes em blocos mais antigos. Desde a Merge, difficulty e nonce são zero, e mixHash contém o valor de aleatoriedade da cadeia Beacon. Os dados anteriores à Merge têm mais um recurso: blocos ommer (tios), blocos válidos que perderam uma disputa, mas foram referenciados por um bloco posterior por meio de sha3Uncles e da lista uncles. Seus mineradores recebiam uma recompensa reduzida sem nenhuma transação; portanto, as análises de recompensas da era da mineração precisam incluí-los. Desde a Merge, a lista está sempre vazia.

Altura versus hash

A altura (o number do Ethereum) é uma posição: a contagem de blocos desde o bloco gênese. O hash do bloco é uma identidade. Dois blocos diferentes podem compartilhar a mesma altura quando a cadeia se bifurca, mas apenas um deles acaba na cadeia principal. Um hash, por outro lado, identifica exatamente um bloco para sempre.

Use a altura por conveniência e para intervalos (“blocos 21.000.000 a 21.000.999”) e o hash para identificar o bloco. No armazenamento, mantenha ambos e use o hash como chave. Ao citar um bloco em um relatório, informe os dois: “altura 880.214, hash 0000…3f1a”. O RPC getblockhash do Bitcoin retorna o hash que está atualmente naquela altura, que pode mudar perto do topo da cadeia; o Ethereum oferece eth_getBlockByNumber e eth_getBlockByHash.

Carimbos de data e hora e sua confiabilidade

O carimbo de data e hora de um bloco é o horário atribuído pelo analista a todas as transações nele contidas. Sua precisão depende da cadeia.

Bitcoin Os carimbos de data e hora são definidos pelo minerador dentro de duas regras: o horário deve ser posterior à mediana dos 11 blocos anteriores (o median time past), e os nós rejeitam blocos com horário mais de duas horas à frente do relógio local (versões mais antigas do Bitcoin Core usavam um horário “ajustado pela rede”, obtido de pares). Portanto, um bloco pode ter um carimbo de data e hora anterior ao do bloco pai, e qualquer carimbo isolado pode estar errado por uma hora ou mais. Para ordenar, use a altura; para um relógio monotônico, o mediantime do Bitcoin Core nunca diminui. Em relatórios, informe os horários do Bitcoin com a precisão que os dados permitem.

Ethereum Desde a Merge (setembro de 2022), o Ethereum tem slots fixos de 12 segundos, e o carimbo de data e hora de um bloco equivale ao horário de gênese mais 12 segundos multiplicados pelo número do slot. Os carimbos de data e hora são exatos e regulares; um intervalo de 24 ou 36 segundos entre blocos consecutivos significa que um ou dois slots ficaram sem bloco. Antes da Merge, os mineradores definiam os carimbos de data e hora sob regras mais flexíveis. Em rollups, o sequenciador define os carimbos de data e hora de acordo com as regras próprias de cada rollup.

Duas ressalvas se aplicam a todos os casos. O horário do bloco é o momento em que uma transação foi incluída, não o momento em que foi assinada ou transmitida. E os horários de “primeira vez vista” exibidos pelos exploradores vêm dos observadores de mempool próprios deles: são pistas úteis, mas locais a um único observador.

Reorganizações

Uma reorganização (reorg) ocorre quando os nós trocam a cadeia que estavam seguindo por uma ramificação concorrente. Os blocos substituídos são chamados de stale ou, no uso comum, órfãos.

No Bitcoin, ocasionalmente dois mineradores encontram blocos quase na mesma altura e no mesmo horário. Os nós seguem a ramificação com mais trabalho acumulado (chainwork) e, quando o bloco seguinte estende um dos lados, o bloco do outro lado fica stale. Suas transações geralmente reaparecem na ramificação vencedora, mas possivelmente em outro bloco e outra posição, ou não reaparecem se uma transação conflitante tiver sido confirmada. O Bitcoin Core lista as ramificações conhecidas com getchaintips, e getblock informa confirmations como −1 para um bloco que não está na cadeia principal.

No Ethereum, a prova de participação torna as reorganizações mais raras e, geralmente, limitadas a um bloco de profundidade. Os registros entregues por assinaturas ou filtros incluem removed: true quando uma reorganização os remove; os pipelines precisam tratar esse sinal.

Finalização para análises

A finalização é o ponto em que um bloco pode ser tratado como permanente.

• Bitcoin A finalização é probabilística. Cada bloco adicional (uma confirmação) torna a substituição exponencialmente mais cara. Seis confirmações é uma convenção comum para transferências de valor, e moedas mineradas recentemente (saídas coinbase) não podem ser gastas por 100 blocos.
• Ethereum Tem finalização econômica explícita. Os slots são agrupados em épocas de 32 slots (6,4 minutos); os validadores votam em pontos de verificação de época, que se tornam justificados e depois finalizados, normalmente após cerca de duas épocas, aproximadamente 13 minutos. Reverter um bloco finalizado exigiria que pelo menos um terço de todo o ETH em staking fosse destruído.

O JSON-RPC do Ethereum expõe isso por meio de tags de bloco aceitas no lugar de um número de bloco: earliest (bloco gênese), latest (o bloco mais recente seguido pelo nó), safe, finalized e pending. O significado de safe depende do cliente de consenso: muitos retornam o ponto de verificação justificado mais recente, alguns minutos atrás de latest, e alguns clientes estão adotando uma regra de confirmação rápida que o aproxima do topo da cadeia em questão de segundos. Verifique o que seu nó retorna em vez de presumir.

A consulta abaixo conta as transações diárias somente até um limite obtido do nó com eth_getBlockByNumber("finalized", false):

-- Contagens diárias de transações, nunca além do bloco finalizado
SELECT DATE_TRUNC('day', b.block_time) AS day_utc,
       COUNT(*)                         AS tx_count
FROM transactions t
JOIN blocks b ON b.block_hash = t.block_hash
WHERE b.block_number <= :finalized_block
GROUP BY DATE_TRUNC('day', b.block_time)
ORDER BY day_utc;

Fazer a junção por block_hash, em vez de por altura, mantém as transações de blocos stale fora da contagem. DATE_TRUNC existe no PostgreSQL e em vários data warehouses; outros mecanismos usam TIMESTAMP_TRUNC ou uma conversão para data.

Tratamento de dados órfãos

Qualquer pipeline que ingira blocos recentes encontrará reorganizações. Um projeto robusto faz quatro coisas: armazena block_hash e parent_hash para cada bloco; a cada novo bloco, verifica se o hash do bloco pai corresponde ao hash armazenado uma altura abaixo; quando não corresponde, volta até o ancestral comum, marca as linhas dos blocos substituídos como não canônicas e ingere a nova ramificação; e mantém as linhas substituídas em uma tabela de auditoria em vez de excluí-las. A verificação abaixo encontra rupturas na cadeia armazenada:

-- Blocos sem bloco pai: lacunas ou reorganizações não tratadas
SELECT c.block_number, c.block_hash, c.parent_hash
FROM blocks c
LEFT JOIN blocks p ON p.block_hash = c.parent_hash
WHERE p.block_hash IS NULL
  AND c.block_number > (SELECT MIN(block_number) FROM blocks);

A tabela de auditoria é importante em investigações. Suponha que um depósito tenha sido creditado após uma confirmação, que o bloco tenha ficado stale e que uma transação conflitante, gastando as mesmas moedas, tenha sido confirmada. Uma página em cache de um explorador ainda pode mostrar a primeira transação. Somente os dados armazenados dos blocos stale permitem que um analista explique por que um depósito “confirmado” nunca existiu na cadeia final.

Foco no exame: os seis campos do cabeçalho do Bitcoin e o fato de que o hash do bloco é calculado, não armazenado; os principais campos do cabeçalho do Ethereum e as atualizações que os adicionaram; altura como posição versus hash como identidade; regras de carimbo de data e hora do Bitcoin (median time past, limite de duas horas) e por que os carimbos de data e hora podem estar fora de ordem; slots de 12 segundos e carimbos de data e hora exatos do Ethereum; reorganizações, blocos stale e registros removed: true; profundidade de confirmações, épocas, pontos de verificação justificados e finalizados e as tags JSON-RPC latest, safe e finalized; detecção e registro de dados órfãos.