Modelos de bloco e Stratum V2

Curiosidade

1. Por que um minerador com hardware dedicado ainda depende de um operador de pool para decidir quais transações entram em um bloco?
2. O que permite que um minerador de grupo escolha as transações em seus próprios blocos, ao mesmo tempo em que ainda compartilha as recompensas do grupo?
3. Como a mudança de JSON para protocolos binários resolve tanto a segurança quanto a eficiência em operações de mineração de alta velocidade?

Explorar

1. Desde o surgimento do protocolo, todo bloco válido requer a seleção de transações. Nos primeiros dias, os mineradores que operavam nós completos escolhiam essas transações por conta própria. Em 2012, com o hardware se tornando cada vez mais especializado e caro, a maioria passou a fazer parte de pools. O protocolo Stratum, introduzido pela Slush naquele ano, padronizou a forma como os servidores dos pools distribuíam o trabalho entre seus membros. Os pools já criavam blocos desde 2010; o Stratum tornou esse processo muito mais eficiente e manteve sua abordagem centralizada na construção dos blocos.
2. Sob o Stratum V1, o operador do pool atua como o único arquiteto de cada bloco candidato. O servidor agrega transações de seu próprio mempool e envia aos mineradores as partes necessárias para a geração do bloco: as duas metades da transação coinbase, o ramo Merkle, o hash do bloco anterior, o alvo e o tempo. O minerador insere seu próprio valor extra-nonce, calcula a raiz Merkle e procura por um hash válido, mas não tem poder de decisão sobre quais transações serão incluídas.
3. Essa arquitetura confere aos operadores de pools poder significativo sobre a seleção das transações. Um pool que controla uma parte substancial da hashrate da rede pode censurar transações efetivamente, simplesmente excluindo-as de seus modelos. Embora isso seja raramente praticado, a capacidade estrutural para isso existe. Isso também significa que, se um servidor do pool falhar ou sofrer um ataque de negação de serviço, todos os mineradores conectados ficarão ociosos, criando um único ponto de falha para sua receita.
4. Em 2012, o BIP22 e o BIP23 introduziram a função `getblocktemplate`, que permitia ao software de mineração solicitar um modelo completo de bloco a um nó. Ela foi projetada para que os membros dos pools pudessem criar seus próprios blocos. Os pools utilizam `getblocktemplate` internamente para obter modelos de seus próprios nós, mas permitir que os membros criassem seus próprios blocos complicou a validação e o compartilhamento das informações contábeis; poucos pools ofereciam essa funcionalidade (o Eligius era uma exceção).
5. O Stratum V2, desenvolvido a partir de 2019 por Braiins e Matt Corallo, entre outros, redesenhou o protocolo para resolver esses problemas. Ele introduz um formato binário para reduzir o consumo de recursos e criptografia para garantir segurança. O que é crucial é que ele inclui o Protocolo de Declaração de Trabalho (Job Declaration). Isso permite que um minerador que opera seu próprio nó completo declare seu próprio modelo de bloco ao servidor do pool. O pool então aceita as contribuições dessa tarefa personalizada, dividindo as recompensas de acordo com seu esquema padrão, enquanto o minerador mantém o controle sobre a inclusão das transações.
6. Esforços alternativos como o protocolo DATUM do Ocean’s (2024) buscam objetivos semelhantes de descentralizar a criação de modelos. Leia a seção de Declaração de Trabalho da especificação Stratum V2 e compare-a com a maneira como um pool que você conhece constrói seus modelos. Nos locais onde esses protocolos são adotados, a escolha das transações volta para os proprietários do hardware.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• BIP22: getblocktemplate – Fundamentals (2012)
• BIP23: getblocktemplate – Pooled Mining (2012)
• Stratum V2 Specification (stratumprotocol.org, from 2019)
• OCEAN mining pool, DATUM protocol documentation (2024)