Bloco Candidato
O bloco que um minerador tenta adicionar à blockchain
-
Greg Walker - Atualizado em
Um bloco candidato é um bloco de transações que um minerador tenta adicionar à blockchain.
Durante a mineração, cada minerador coleta transações do seu memory pool em um bloco candidato. Ele então faz o hash desse bloco repetidamente para tentar obter um hash de bloco abaixo do alvo.
Se um minerador conseguir um hash de bloco abaixo do alvo, o seu bloco candidato pode ser adicionado à blockchain.
Ele então transmite esse bloco candidato "minerado" aos outros nós da rede, onde cada nó o verifica e o adiciona à sua blockchain também.
Em outras palavras, um bloco candidato representa o próximo bloco de transações a ser adicionado à blockchain.
Exemplo
Como é um bloco candidato?
Veja como era o cabeçalho de um bloco candidato em um determinado instante, segundo um nó:
Instantâneo de exemplo (não ao vivo). A visualização em tempo real do bloco candidato — com as transações do mempool — depende de um nó próprio; a versão dinâmica via API pública fica para a Fase 3 do projeto.
Cabeçalho do Bloco
| Versão | 0x20000000 |
|---|---|
| Bloco Anterior | 0000000000000000000109034ee4e258865d51a6a37f9de255a9534f04dab40b |
| Raiz de Merkle | 52f71c77876c5617f399078238fffe9b791e314b3bfc590f5ba0ae770bbcf120 |
| Tempo | 13 jun 2026, 19:04:12 |
| Bits | 1702068f |
| Nonce | 0 |
Transações
- Neste exemplo, ninguém está ativamente tentando minerar este bloco. Para minerar, seria preciso ajustar o nonce no cabeçalho do bloco para tentar obter um hash de bloco abaixo do alvo atual.
- Também não há uma transação coinbase própria neste bloco candidato, então ele não seria válido se fosse minerado assim. Este exemplo serve apenas para mostrar como é um bloco candidato.
- Se a raiz de Merkle muda, você sabe que as transações do bloco mudaram.
- As transações de menor taxa, mais para o fim do bloco candidato, são as mais propensas a mudar.
Construção
Como você constrói um bloco candidato?
Há três passos básicos para construir um bloco candidato:
1. Selecionar transações
O primeiro passo é selecionar transações do memory pool que você quer incluir no seu bloco candidato.
Um minerador normalmente enche o seu bloco candidato com as transações de maior taxa para maximizar o quanto pode reivindicar da recompensa do bloco.
2. Construir a transação coinbase
A transação coinbase é a primeira transação de um bloco e é usada pelo minerador para reivindicar a recompensa do bloco.
A razão de construir a transação coinbase depois de selecionar as transações é que ela precisa conter um hash de raiz da testemunha, calculado com base nas transações que foram incluídas no bloco.
3. Construir o cabeçalho do bloco
O cabeçalho do bloco é uma pequena quantidade de metadados que resume todos os dados do bloco. É o que um minerador faz o hash ao tentar minerar o bloco candidato.
O cabeçalho do bloco contém seis campos diferentes (versão, bloco anterior, raiz de Merkle, tempo, bits, nonce), mas estes dois são os mais pertinentes:
- Bloco Anterior: este campo é usado para especificar um bloco existente sobre o qual o bloco candidato será construído. Os mineradores sempre querem construir sobre a ponta da blockchain, pois só podem reivindicar a recompensa do bloco se o bloco que minerarem acabar fazendo parte da cadeia mais longa.
- Raiz de Merkle: a raiz de Merkle é uma impressão digital de todas as transações incluídas no bloco. Isso é importante porque significa que você não pode mudar o conteúdo do bloco sem mudar a impressão digital. Então, novamente, é por isso que construímos o cabeçalho do bloco depois de selecionar as transações para o bloco candidato.
Cabeçalho do Bloco
E pronto, a construção do bloco candidato está completa. A partir daqui, o minerador pode começar a trabalhar na mineração do bloco candidato para tentar adicioná-lo à blockchain.
Requisitos
Quais são os requisitos de um bloco candidato?
Um bloco candidato tem alguns requisitos básicos:
1. Transação coinbase
A primeira transação do bloco candidato precisa ser a transação coinbase.
Essa transação é colocada no bloco pelo minerador para reivindicar a recompensa do bloco.
Isso significa que todos os blocos sempre conterão pelo menos uma transação.
2. Transações válidas
Todas as transações que um minerador inclui no seu bloco candidato precisam ser válidas.
Por exemplo, cada transação só pode gastar moedas que já existem.
Se um minerador minera um bloco contendo transações inválidas e o transmite à rede, todos os nós o rejeitarão, e todo o esforço de mineração do bloco terá sido desperdiçado.
3. Pais das transações
O(s) pai(s) de uma transação precisam sempre vir antes da transação-filha.
Por exemplo, se uma transação tem ancestrais que estão atualmente no mempool, esses ancestrais precisam ser incluídos acima dela no bloco candidato.
Cada nó valida as transações de um bloco de cima para baixo, então, se você incluir um pai depois de um filho, parecerá que aquela transação-filha está gastando saídas que ainda não existem (e ela seria, portanto, inválida).
4. Limite de tamanho
O tamanho máximo de um bloco é de 4.000.000 unidades de peso.
Então, as transações que você inclui no seu bloco candidato (incluindo o tamanho do cabeçalho do bloco e a contagem de transações) precisam ficar dentro desse limite de tamanho.
O limite de tamanho do bloco pode ser encontrado em consensus.h.
5. Operações de assinatura
Um bloco é limitado a um máximo de 80.000 operações de verificação de assinatura. Então, as transações que você inclui no seu bloco candidato precisam ficar dentro desse limite.
Isso porque a verificação de assinatura é demorada, então esse limite impede que mineradores criem blocos que seriam excepcionalmente lentos de validar.
As operações de verificação de assinatura são realizadas por opcodes do Script, como: OP_CHECKSIG, OP_CHECKMULTISIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY.
- O limite de sigops também pode ser encontrado em consensus.h.
- Segregated Witness: de forma parecida a como os bytes de uma transação legada são multiplicados por 4 para calcular o seu peso equivalente, a contagem de operações de assinatura em transações legadas também é multiplicada por 4. Então, enquanto um único OP_CHECKSIG conta como 1 operação de assinatura quando está no campo Witness (como esperado), ele conta como 4 operações de assinatura quando está no ScriptSig (ver validation.cpp).
Seleção de Transações
Como os mineradores selecionam as transações do bloco candidato?
Um minerador pode encher o seu bloco candidato com quaisquer transações que quiser do memory pool.
Porém, normalmente os mineradores buscam encher o seu bloco candidato com as transações de maior taxa disponíveis, para maximizar o quanto podem reivindicar da recompensa do bloco.
Então, se há mais transações no memory pool do que cabem em um bloco candidato, o minerador prioriza as transações de maior taxa para incluir no seu bloco.
Taxa de Ancestrais
Há uma regra importante que os mineradores precisam seguir ao selecionar transações:
Você só pode incluir uma transação em um bloco se também incluir todos os seus pais antes.
Portanto, se uma transação do memory pool tem ancestrais, o minerador calcula a taxa de ancestrais para descobrir se vale a pena incluí-la, em comparação com outra transação que não tem ancestrais.
Quando há ancestrais no memory pool, o processo de selecionar a combinação ótima de transações é complexo, e a única forma de obter o bloco "perfeito" em termos de maximizar as taxas é testar todas as combinações possíveis. Por isso, a maioria dos mineradores faz uma tentativa de melhor esforço para montar um bloco com transações de taxa alta, sem perder tempo tentando calcular o bloco "perfeito" a cada vez.
Blocos Vazios
Por que os mineradores mineram blocos vazios?
Às vezes você encontra "blocos vazios" aparecendo na blockchain, com apenas uma transação dentro.
Por exemplo, o bloco 828.012 não contém nenhuma transação (além da transação coinbase obrigatória), enquanto os blocos acima e abaixo dele estão cheios de transações:
| Altura | Hash do Bloco | Txs | Tamanho | Taxa Média | Hora (UTC) |
|---|---|---|---|---|---|
| 828.015 | 00000000000000000000a9c619c4af8c09f10c11a8262bcde576450e45a126ca | 3.142 | 1.00/1.00 vMB | 31 | 29 jan 2024, 21:54 |
| 828.014 | 000000000000000000015b4c953a7636418316bee66575d79edf407a3f9640ae | 5.222 | 1.00/1.00 vMB | 30 | 29 jan 2024, 21:48 |
| 828.013 | 000000000000000000023cbbedc89f62a4e38db462bb45b5214d12f0f85f1972 | 4.385 | 1.00/1.00 vMB | 33 | 29 jan 2024, 21:44 |
| 828.012 | 00000000000000000003eb119d2115448bea2d14e18bf19c00020dd23fee79cb | 1 | 0.00/1.00 vMB | 0 | 29 jan 2024, 21:41 |
| 828.011 | 0000000000000000000300773e6ec30fbed5d49a07568114c5824c7f89401fc9 | 5.639 | 1.00/1.00 vMB | 29 | 29 jan 2024, 21:33 |
| 828.010 | 000000000000000000004cdc62634f083ec10dffc7bb4777c792d67c0aefbf8b | 3.881 | 1.00/1.00 vMB | 29 | 29 jan 2024, 21:32 |
| 828.009 | 00000000000000000000ce872172185086c9c6cfbedd0e78e90b6d0a7bd93f07 | 2.557 | 1.00/1.00 vMB | 38 | 29 jan 2024, 21:31 |
Isso acontece porque os mineradores normalmente começam a trabalhar em um bloco candidato vazio enquanto selecionam as transações do memory pool.
Como mencionado, leva um tempo para um minerador calcular a combinação ótima de transações para maximizar o valor em taxas que pode reivindicar. Então, em vez de ficar parado enquanto calcula quais transações incluir no seu bloco, ele começa imediatamente a minerar um bloco vazio primeiro.
Como consequência, às vezes um minerador tem sorte e minera o seu bloco vazio antes de chegar a trabalhar em um bloco candidato cheio de transações.
Isso não acontece com muita frequência, mas explica por que às vezes você vê "blocos vazios" na blockchain.
Embora o minerador perca a oportunidade de reivindicar as taxas das transações ao minerar um bloco vazio, é mais lucrativo para ele começar a minerar um bloco vazio pela chance de reivindicar o subsídio do bloco nesse meio-tempo.
Comandos
bitcoin-cli getblocktemplate [template_request]
Retorna transações do memory pool do seu nó que você pode usar para construir um bloco candidato.
O chato é que você também precisa fornecer um array meio esquisito para especificar o tipo de modelo de bloco que quer (veja a BIP22). É isto que eu costumo usar: bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'
Você precisará construir o cabeçalho do bloco manualmente a partir desse modelo de bloco antes de começar a minerar. Por exemplo, você precisará construir a sua própria transação coinbase, além de calcular a raiz de Merkle. Então é mais um "ponto de partida", mas ele faz o trabalho pesado de selecionar uma combinação ótima de transações do memory pool para maximizar as taxas que você pode reivindicar.
Notas
- Não existe um único bloco candidato em que todos os mineradores trabalham. Cada minerador seleciona transações do seu próprio mempool, então, embora normalmente haja uma grande sobreposição, costuma haver pequenas diferenças entre os blocos candidatos. Por isso, se você vê que a sua transação está atualmente em um bloco candidato, não há garantia de que ela será incluída no próximo bloco (embora seja provável que sim).