Mining Pool

Anna tem uma máquina de mineração. Paga eletricidade todos os dias, mas, se minerar sozinha, poderá esperar muito tempo até encontrar um bloco. Se encontrar um bloco aceite pela rede, recebe a respetiva recompensa; até lá, não recebe nada dessa mineração. Uma espera longa também não significa que o sucesso esteja próximo. Mantendo-se as condições, cada nova tentativa tem a mesma probabilidade. Num pool, a sua máquina trabalha com outras. O pool pode remunerar quem não encontrou um determinado bloco, porque mede os contributos e aplica um modelo acordado. Anna abdica de ficar com toda a receita do seu próprio bloco em troca de montantes menores e geralmente mais regulares. Isto não reduz a dificuldade da rede nem cria recompensas adicionais. Além disso, o pool costuma cobrar uma taxa. Saber se a receita paga a eletricidade e o equipamento é outra questão. [6] [7]

O pool não vê todos os cálculos da máquina de Anna. Precisa, porém, de verificar que está a trabalhar e de estimar o seu contributo. Por isso, estabelece uma condição mais fácil do que a da rede Bitcoin. Um resultado que a cumpra chama-se Mining Share, ou share. A máquina pode assim enviar resultados verificáveis com regularidade, mesmo sem encontrar um bloco. Com as shares aceites e a respetiva dificuldade, o pool estima estatisticamente o trabalho. Não é uma contagem exata de todas as tentativas. Se dois aparelhos tiverem dificuldades de share diferentes, os números de resultados não são diretamente comparáveis. Uma share normal não cria um bloco nem confirma um pagamento. Só um resultado raro que cumpra também a condição da rede permite apresentar um bloco, que terá ainda de passar as restantes verificações. Uma share comprova trabalho perante o pool; não é um pedacinho de bitcoin acabado de produzir. [7] [9]

Anna pode ligar a mesma máquina a pools diferentes e observar rendimentos distintos. Uma razão é o modelo de cálculo. PPS, Pay Per Share, credita um valor esperado previamente definido por cada share aceite, de acordo com a sua dificuldade. Anna não tem de esperar que o pool tenha sorte e encontre um bloco: o operador assume o risco das variações aleatórias nas descobertas. Isto não garante que consiga sempre pagar nem corresponde a um salário fixo à hora. O número de shares e as condições de mineração continuam a variar. FPPS, Full Pay Per Share, costuma juntar uma estimativa das taxas de transação à parte esperada dos bitcoins recém-emitidos. Já PPLNS, Pay Per Last N Shares, distribui a receita dos blocos efetivamente encontrados segundo o trabalho numa janela recente definida. A remuneração depende mais da sorte do pool. As regras determinam essa janela; não tem de ser simplesmente a última hora. A sigla não basta para comparar. Contam também as taxas, o método de estimativa, a dimensão da janela e o tratamento dos blocos fora do histórico principal, os Stale Blocks. O modelo determina o direito à recompensa e o seu cálculo; o calendário de transferências para a carteira é uma regra separada. [7] [8]

Anna vê o saldo da conta aumentar. Enquanto não chegar à sua carteira, depende de o pool o contabilizar corretamente e o pagar. Convém conhecer a data de pagamento, o eventual mínimo exigido, as taxas e o endereço de destino. Os serviços diferem: creditar recompensas automaticamente não significa transferi-las de imediato. Também é preciso acompanhar o funcionamento: shares aceites ou rejeitadas, a sua dificuldade chamada Share Difficulty, disponibilidade dos servidores e ligações de reserva. O firmware é o software de controlo do mineiro e tem de funcionar com o pool. Comparar registos do pool de um período mais longo com os próprios registos operacionais e os pagamentos recebidos ajuda a detetar diferenças. Os blocos encontrados podem ser verificados na blockchain, mas esta não revela toda a contabilidade interna do pool. Poder mudar de pool e saber quem escolhe as transações também importa. [8] [9]

Se a tarefa mudar antes de chegar o resultado, o pool poderá deixar de o contabilizar. Latência significa aqui o atraso na comunicação entre aparelho e pool. Uma share pode ser rejeitada por estar desatualizada (stale), duplicada, mal construída ou não corresponder à tarefa atribuída. Uma maior latência entre o mineiro e o pool, atualizações lentas das tarefas e falhas de rede aumentam o trabalho perdido. A proporção de stale shares informa, por isso, sobre a eficiência operacional da ligação entre o mineiro e o pool; não é o mesmo que um Stale Block na blockchain. [9]

A recompensa do bloco fica registada numa primeira transação especial chamada Coinbase Transaction. As suas saídas indicam os montantes e as condições para os gastar mais tarde. A recompensa pode, por isso, destinar-se a um ou vários destinatários. Block Template é a proposta de bloco com as transações escolhidas. Num pool tradicional, o operador do pool constrói normalmente o Block Template e determina também o destinatário da saída coinbase. O mineiro experimenta sobretudo diferentes valores na tarefa que lhe foi atribuída, procurando um resultado que satisfaça a condição da rede. O pool ganha assim influência sobre a seleção de transações, mas não a capacidade de impor um bloco inválido; cada Full Node verifica o bloco de forma independente. Full Node é um programa que verifica os blocos e as transações segundo as regras do Bitcoin. [6] [10]

Além do montante pago, importa quem decide quais os pagamentos incluídos nos blocos. Excluir determinadas transações pode atrasar a confirmação. A concentração dos pools é importante porque um pequeno número de coordenadores pode influenciar a inclusão de transações, a adoção de software e a distribuição do Hashrate a curto prazo. Hashrate é o número de cálculos de mineração por segundo. Porém, o Hashrate de um pool não equivale à propriedade dos equipamentos de mineração: os operadores de máquinas especializadas em mineração, chamadas ASIC, podem ligá-las a outro pool. O risco aumenta se os custos de mudança de pool, os contratos ou o firmware limitarem essa possibilidade. [6] [10]

Stratum define a comunicação entre mineiro e pool. A cifragem protege as mensagens transmitidas e a autenticação ajuda a verificar a outra parte. O Stratum V1 serve para atribuir trabalho de mineração, e o controlo do modelo permanece normalmente no pool. O Stratum V2 separa mais claramente as funções e suporta comunicação cifrada e autenticada. O Job Declaration Protocol opcional permite ao mineiro apresentar o seu próprio modelo com a sua seleção de transações, se tanto o mineiro como o pool suportarem os componentes necessários. O Mining Protocol do Stratum V2 pode funcionar sem essa possibilidade; a designação Stratum V2 não garante, por si só, uma seleção independente de transações. [10]

Para conhecer o mecanismo: Block Template é uma proposta de conteúdo para um bloco. Worker identifica uma máquina ligada ou a conta à qual o seu trabalho é atribuído; o cabeçalho resume os dados essenciais do bloco. Uma tarefa de mineração parte de um Block Template ou de uma construção equivalente de um bloco candidato. O BIP22 descreve getblocktemplate e o BIP23 as suas extensões para mineração em pool. O protocolo do pool transmite aos workers os campos necessários, os dados da transação coinbase e o espaço de pesquisa. Um ASIC Miner experimenta diferentes cabeçalhos e calcula o seu hash, uma impressão digital numérica. Para satisfazer Proof of Work, a prova do trabalho de cálculo, esse hash tem de ser menor ou igual ao limite da rede, chamado target. O bloco tem ainda de cumprir as restantes regras do Bitcoin. [1] [2] [5]

Pormenor técnico: target é um limite numérico que o hash, resultado do cálculo, não pode ultrapassar; a igualdade também serve. VarDiff significa dificuldade variável das shares. O pool define um share target mais fácil para receber resultados com frequência suficiente para efetuar medições. O target da rede Bitcoin é muito mais difícil de satisfazer. Uma share aceite que satisfaz apenas o target do pool é contabilizada segundo as regras de remuneração desse pool; se o mesmo hash satisfizer também o target da rede, pode ser apresentado um bloco candidato. VarDiff altera a dificuldade das shares e, consequentemente, a sua frequência, não a Difficulty de consenso do Bitcoin. [9]