Bloco serializado

A serialização é como um bloco abstrato se transforma em algo cujo hash você pode calcular e que pode ser enviado e armazenado. O bloco gênesis é serializado em 285 bytes: 80 para o cabeçalho, 1 para a contagem de transações e 204 para sua única transação coinbase. Se você já colou hexadecimal bruto em um explorador de blocos ou executou getblock com verbosity 0, isto é o que você estava vendo.

Como funciona

Três partes ficam uma após a outra em um bloco serializado, e apenas a primeira tem comprimento fixo.

O cabeçalho sempre ocupa 80 bytes, nesta ordem: uma versão de 4 bytes, o hash de 32 bytes do cabeçalho anterior, a raiz de merkle de 32 bytes, um carimbo de data e hora de 4 bytes, a codificação de alvo nBits de 4 bytes e um nonce de 4 bytes. Em seguida vem o número de transações, escrito em compactSize, um inteiro de comprimento variável que ocupa 1 byte para contagens abaixo de 253 e até 9 bytes para qualquer valor enorme. Depois vêm as próprias transações, cada uma totalmente serializada, com a coinbase primeiro.

Desde o BIP144, o mesmo bloco tem duas serializações válidas. A forma despojada deixa as testemunhas de fora por completo e é o que o software anterior a 2017 espera. A forma completa as inclui, marcando cada transação que carrega testemunha com um byte 0x00 seguido de um sinalizador 0x01 onde de outro modo estaria a contagem de entradas. Ambas codificam o mesmo bloco e ambas produzem o mesmo hash de bloco, porque o hash cobre apenas aqueles 80 bytes do cabeçalho e a raiz de merkle dentro deles é um compromisso com os IDs de transação, que são calculados a partir da codificação despojada. Essa separação é o significado literal de testemunha segregada.

Um hábito pega todo mundo pelo menos uma vez: inteiros de vários bytes são escritos em little endian, então o carimbo de data e hora 0x495FAB29 aparece na rede como 29 ab 5f 49, e os hashes são exibidos na ordem inversa à de seus bytes serializados. Um hash de bloco que você copia de um explorador não é a sequência de bytes que está no arquivo.

Onde você o vê

Os blocos serializados viajam pela rede ponto a ponto dentro de uma mensagem block. Cada mensagem carrega primeiro um envelope de 24 bytes: uma string de início de 4 bytes, f9beb4d9 na mainnet, um nome de comando de 12 bytes, um comprimento de carga útil de 4 bytes e uma soma de verificação de 4 bytes obtida dos quatro primeiros bytes de um SHA-256 duplo sobre a carga útil. O Bitcoin Core limita a carga útil de qualquer mensagem individual a 4.000.000 bytes, um limite da rede e não de consenso.

Os mesmos bytes chegam ao seu disco. O Bitcoin Core acrescenta blocos a arquivos chamados blk00000.dat e seguintes, cada um limitado a 128 MiB, com a mesma string de início e um prefixo de comprimento antes de cada bloco, para que o arquivo possa ser escaneado linearmente. O gênesis é a exceção: ele é compilado no software como uma constante em vez de ser baixado, e é isso que o torna a âncora pela qual um nó em sincronização mede todo o resto.

No uso diário, a serialização aparece por meio do getblock RPC com verbosity 0, na aba de dados brutos ou hexadecimal da maioria dos exploradores e dentro de ferramentas que permitem decodificar um bloco à mão. Quem verifica se um explorador lhe disse a verdade acaba aqui, porque o hexadecimal é a única representação que ninguém reformatou.

Bloco serializado vs bloco

Um bloco é o objeto; um bloco serializado é uma codificação dele. A distinção era cosmética até 2017, quando o SegWit deu a cada bloco duas codificações válidas de comprimentos diferentes, de modo que o tamanho de um bloco se tornou uma pergunta que precisa de qualificação. O Bitcoin Core a responde de três maneiras em uma única resposta RPC: size para a serialização completa, strippedsize para a sem testemunhas e weight para o número que as regras realmente aplicam.