Slush Pool: uma ideia praguense contra a loteria de mineração

Na época, o Bitcoin recompensava o vencedor de um bloco com cinquenta moedas. Para a rede, era um mecanismo simples, mas para os indivíduos, era uma loteria dura. A probabilidade de encontrar um bloco correspondia à proporção de seu poder de processamento em relação à rede inteira. À medida que o poder de processamento total crescia, um pequeno minerador podia esperar cada vez mais, mesmo que seu computador funcionasse sem parar.

A média de longo prazo podia parecer favorável, mas as contas de eletricidade chegavam todos os meses. O indivíduo precisava suportar um grande risco: ou ganhava a recompensa integral, ou nada durante um longo período. Isso expulsava as pessoas com menor poder de processamento, mesmo que seu trabalho fosse tão útil para a rede quanto o de uma grande operação.

Palatinus conhecia o problema por experiência própria. No fórum, ele descreveu como um servidor comum podia unir milhares de pequenas tentativas e dividir os resultados. O participante não precisaria mais esperar por seu próprio sucesso raro; receberia uma parte menor a cada vez que alguém no grupo encontrasse um bloco.

O pool de mineração não muda a probabilidade do grupo inteiro nem cria mais bitcoins. Ele muda a distribuição do risco ao longo do tempo. É a diferença entre um único bilhete de loteria com um grande prêmio e uma participação regular em um grande lote de bilhetes. Em troca de uma renda mais estável, o minerador paga uma taxa e depende da contabilidade correta do operador.

Slush não apresentou sua proposta como uma vitória puramente técnica. Já no primeiro tópico, ele listou as vantagens, desvantagens e a confiança necessária. O servidor precisava medir corretamente o trabalho realizado, não roubar recompensas e permanecer acessível. O pool eliminava uma incerteza, mas adicionava um intermediário que o próprio consenso bitcoin não controlava.

Para o pequeno minerador, o maior problema não era o rendimento médio, mas o tempo. Estatisticamente, podia ter direito a uma fração da recompensa todos os dias, mas o protocolo real não pagava frações por esforço. Ou a sua máquina encontrava um bloco válido e recebia cinquenta bitcoins inteiros, ou não recebia nada. Uma longa série de insucessos, no entanto, não significava que o equipamento não estava a funcionar; significava apenas que a lotaria ainda não tinha caído a seu favor. Um servidor comum convertia este evento irregular em partes menores, de acordo com o trabalho comprovado. O pool não aumentava o número esperado de blocos encontrados, mas alterava o ritmo da receita, e era precisamente esta diferença que podia determinar se uma pessoa podia continuar a minerar.

O anúncio de 27 de novembro de 2010 não foi um produto corporativo pronto. Palatinus procurava pessoas dispostas a testar o protocolo, a conexão e o método de recompensa. O sistema precisava aceitar provas parciais de trabalho — resultados muito fracos para um bloco válido, mas suficientes para provar que o minerador realmente estava processando.

Esses resultados parciais, chamados shares, permitiam ao pool estimar a contribuição de cada máquina. Quando um participante encontrava um hash que atendia à dificuldade de toda a rede, o pool recebia a recompensa do bloco e a distribuía conforme a regra de cálculo escolhida. Para o minerador comum, pagamentos irregulares de cinquenta bitcoins davam lugar a uma sequência de pagamentos menores.

A primeira forma do serviço funcionava sob o nome de Bitcoin.cz Mining Pool. O site, o servidor e o suporte eram, em grande parte, obra de uma única pessoa. Isso dá ao primado tcheco uma dimensão mais precisa: não se tratava de um projeto nacional ou um programa estatal, mas de um programador que, a partir de Praga, resolveu um problema econômico específico da rede global.

O pool também precisava montar um bloco candidato e distribuir a tarefa aos mineradores. As máquinas individuais forneciam o poder de processamento, mas o operador determinava em qual cabeçalho elas trabalhavam e quais transações a estrutura continha. A divisão do hardware entre muitas pessoas, portanto, não garantia por si só a divisão da tomada de decisões.

O desenvolvimento posterior dos protocolos de mineração, incluindo o Stratum V1, buscou otimizar a comunicação entre os pools e os dispositivos. O comércio básico, no entanto, permaneceu o mesmo: o pool vende um pagamento mais previsível, e o minerador confia a ele parte da coordenação. O primeiro servidor criou um padrão que os outros seguiram rapidamente.

A operação real começou em 16 de dezembro de 2010. No mesmo dia, o pool minerou o bloco 97.834. O registro na cadeia de blocos hoje mostra o resultado, mas não a tensão que o antecedeu: se o servidor aceitaria corretamente o trabalho, reconheceria um bloco válido e creditaria as partes aos participantes que contribuíram com poder de processamento.

O primeiro bloco confirmou que a coordenação funcionava não apenas em testes. A recompensa podia ser dividida entre os participantes, a maioria dos quais, de outra forma, não teria ganhado nada naquele momento. Para os pequenos mineradores, foi uma prova tangível de que suas máquinas mais fracas não precisavam ser imediatamente expulsas da economia da rede.

A data é importante para distinguir do anúncio de novembro. A ideia, o teste público e o resultado real foram três etapas diferentes. A história não começa com o bloco sendo encontrado de repente, mas com as semanas que o antecederam, quando Slush descreveu abertamente a proposta e pediu à comunidade que o ajudasse a encontrar erros.

O sucesso atraiu mais poder de processamento e, com ele, a responsabilidade. Quanto maior a parte da rede que o pool reunia, mais sensível era cada falha ou má decisão. O serviço precisava proteger as contas, calcular as recompensas e responder a ataques. Já não se tratava apenas de um script para equalizar a sorte; era uma infraestrutura cuja contabilidade as pessoas confiavam.

O bloco 97.834, portanto, não é significativo por sua quantia. Outros mineradores também ganhavam os mesmos cinquenta bitcoins. O que foi excepcional foi a maneira como eles chegaram lá e como o dividiram. Uma única linha no blockchain representava o trabalho comum de muitas máquinas e a primeira prova prática de que a formação de pools podia funcionar na rede pública.

O projeto mais tarde passou a se chamar Slush Pool e Braiins Pool. A equipe Braiins profissionalizou o serviço, enquanto Marek Palatinus dedicou mais energia ao SatoshiLabs e à carteira de hardware Trezor. Do servidor original, no entanto, permaneceu uma linha histórica ininterrupta até um dos nomes mais antigos da mineração de bitcoin.

A formação de pools expandiu a possibilidade de mineração, mas também concentrou gradualmente a criação de modelos de blocos em um número menor de serviços. O minerador solo decide sozinho que bloco construir. O participante de um pool comum frequentemente apenas processa a tarefa que recebeu. O poder de processamento pode estar disperso, enquanto a tomada de decisões de coordenação permanece centralizada.

Essa concentração não significa que o pool possua todas as máquinas conectadas. Os mineradores podem redirecionar seu poder de processamento para outro lugar se discordarem das taxas, censura ou comportamento do operador. A mudança, no entanto, requer informações e disposição para reagir. A descentralização, portanto, é medida não apenas pelo número de dispositivos, mas também por quem constrói os blocos e quão facilmente se pode mudar o coordenador.

O primeiro texto de Slush não ocultou esse compromisso. Ele ofereceu uma solução para o problema econômico e nomeou a confiança que a solução exigia. É justamente essa abertura que ajuda a ler a história sem o triunfalismo posterior: o pool não foi a resposta final, mas uma nova ferramenta com custos claros.

O projeto praguense mudou a mineração ao separar o trabalho da sorte. O indivíduo não precisava mais ganhar o bloco inteiro sozinho para que seu poder de processamento recebesse um preço contínuo. Ao mesmo tempo, mostrou que mesmo um sistema projetado sem um banco central criaria serviços aos quais as pessoas confiariam a coordenação. A questão não é se esses serviços surgirão, mas se os participantes poderão controlá-los, abandoná-los e substituí-los.

Portanto, a concentração dos pools não pode ser medida apenas pelo número de máquinas ligadas. O que importa é quem monta o modelo do bloco, seleciona as transações, define as regras de pagamento e consegue convencer os participantes a alterar o software quando surge um problema. Um minerador só pode abandonar um pool se tiver outra opção utilizável e se realmente acompanhar o que o serviço faz. A descrição original de confiança de Slush continua a ser pertinente neste sentido. O pooling resolveu um problema económico real e, ao mesmo tempo, criou uma nova área em que são necessários a concorrência, a transparência e a possibilidade de saída. A descentralização não se mantém proibindo a coordenação, mas sim não deixando que esta endureça num poder incontrolável.