Como os protocolos P2P procuram resolver a centralização da mineração de Bitcoin

Os pools de mineração de Bitcoin dependem da centralização, mas o P2Pool e outros protocolos procuraram reduzir a necessidade de confiança em terceiros.

Em um artigo do artigo anterior, escrevi sobre a natureza da descentralização versus centralização na mineração de Bitcoin e como conceituar isso em um sentido principalmente qualitativo. O artigo detalhou toda a pilha de mineração, desde a coordenação do pool até a produção de energia para dar uma ideia da relação entre as diferentes camadas da pilha de mineração e o potencial para maximizar a descentralização, ressaltando que quanto mais abaixo na pilha você ir para a produção de energia, mais difícil e intensivo em capital se torna trazer um nível significativo de descentralização para essa camada.

Neste artigo, pretendo aprofundar o tópico de pools de mineração e coordenação de mineradores para facilitar operações de mineração de propriedade independente cooperando em um esforço para minerar blocos para anexar ao blockchain.

A criação de pools de mineração

A mineração percorreu um longo caminho desde os dias em que você podia simplesmente clicar em um botão e minerar blocos de forma confiável sozinho em uma CPU de laptop. Naquela época, era efetivamente um empreendimento amador amador que não exigia investimento de capital ou experiência real, mas hoje é um mercado profissional multibilionário com investimento de capital maciço necessário em escala. É um jogo de bola totalmente diferente.

Uma das consequências naturais dessa mudança na natureza da indústria de mineração foi a criação de pools de mineração muito cedo. Quando a mineração estava efetivamente deixando um laptop rodando no canto, a variação e a imprevisibilidade de quando você encontraria um bloco não era realmente um grande problema - eventualmente, você o faria e o custo de energia para manter um laptop funcionando não era realmente econômico importância.

Uma vez que as coisas mudaram para GPUs e ASICs, houve um custo de investimento material inicial e um custo de eletricidade muito mais significativo para mantê-los operando. Essa imprevisibilidade de quando você encontraria um bloco se tornou um problema muito maior para os mineradores que tentavam obter retorno sobre seus investimentos de capital e operar com lucratividade. É aqui que os pools de mineração entram em cena.

Eles permitem que os mineradores cooperem para encontrar um cabeçalho de bloco válido trabalhando no mesmo bloco juntos, enviando a recompensa da base de moedas para o pool de mineração, que então a distribui proporcionalmente entre todos os mineradores participantes em relação a quanto trabalho eles fizeram para ajudar a encontrar o bloco. Isso é comprovado ao entregar “ações” ao pool de mineração; blocos que não atendem à meta de dificuldade da rede, mas são altos o suficiente para provar que um minerador não está mentindo e está realmente executando o hardware e tentando encontrar um bloco válido.

Centralização do pool de mineração

Os pools de mineração centralizados trazem grandes implicações para os mineradores individuais. Eles são um ponto de centralização no processo de seleção (ou, mais importante, de exclusão) de transações para inclusão em um bloco. Isso dá a cada operador de pool de mineração controle total sobre as transações que eles escolhem processar no blockchain, sem capacidade para os proprietários reais do hardware de mineração exercerem uma palavra sobre isso, exceto deixando o pool se discordarem dos critérios que o operador escolhe definir.

Eles também guardam bitcoins de mineradores individuais até que esses mineradores optem por retirá-los do pool, deixando o operador do pool agindo como um custodiante e ponto central que poderia fraudar os mineradores usando o pool, ou ser pressionado pelos governos a apreender fundos de mineradores individuais ou aplicar KYC requisitos para eles.

Então, quais soluções existem para resolver esse problema?

P2Pool: o pool de mineração descentralizado original

Piscina P2 é o protocolo de pool de mineração descentralizado original. É um protocolo ponto a ponto no qual os mineradores coordenam entre si para dividir as recompensas de mineração enquanto trabalham juntos para encontrar um bloco válido que atenda à meta de dificuldade. Essa coordenação é realizada usando o que o design do protocolo chama de “sharechain”.

Os mineradores no P2Pool pegam blocos que não atendem à meta de dificuldade da rede e efetivamente mineram seu próprio blockchain composto de todas as cópias do bloco único em que o pool está trabalhando. Quando eles atingem o alvo de dificuldade menor, onde o bloco seria transformado em um pool para provar que estão minerando em um modelo centralizado, eles transmitem esse bloco para o resto dos mineradores. A “dificuldade de compartilhamento” do P2Pool foi direcionada para que os mineradores encontrassem um compartilhamento aproximadamente uma vez a cada trinta segundos.

Tenho certeza de que os leitores estão se perguntando como funciona o pagamento para mineradores individuais. A transação coinbase é estruturada para que uma saída seja criada para cada minerador individual no P2Pool, dividindo os fundos diretamente da transação coinbase. Os mineradores no P2Pool verificam se todos os pagamentos para si mesmos e para todos os participantes do pool estão corretos e que cada minerador que contribuiu com um compartilhamento para o sharechain é pago corretamente por seu trabalho em cada novo compartilhamento adicionado. Se algum minerador participante não estiver estruturando corretamente os pagamentos para todos em seu último compartilhamento, todos os outros mineradores no P2Pool param de incluí-los em seus próprios pagamentos e efetivamente “expulsam” aquele minerador do pool por não se comportar de maneira justa.

Esse design levou a alguns problemas de dimensionamento e é por isso que não está mais em uso. À medida que a participação em um P2Pool cresce, o mesmo acontece com o objetivo de dificuldade agregada para compartilhamentos no sharechain, que são direcionados aproximadamente uma vez a cada trinta segundos. Isso significa que, para mineradores menores, fica mais difícil atingir a dificuldade do sharechain em qualquer período de trinta segundos. Isso significa que, para mineradores menores, a variação, ou imprevisibilidade, em sua renda aumenta à medida que a taxa de hash agregada em um P2Pool aumenta. Isso também leva a um número maior de blocos obsoletos, já que mais mineradores estão encontrando compartilhamentos concorrentes para o sharechain aproximadamente ao mesmo tempo em que mais mineradores se juntam ao P2Pool, levando a “trabalho desperdiçado” do ponto de vista dos mineradores individuais que só obtêm compensados ​​se sua parte for incluída na cadeia de ações.

O outro principal problema de escalabilidade está nos pagamentos que vão diretamente para os mineradores individuais da própria transação da base de moedas. Dado que cada minerador é pago proporcionalmente às ações que mineraram e que estão incluídas no sharechain, cada minerador no P2Pool requer uma nova saída adicionada na transação coinbase.

Isso tem duas consequências. Primeiro: os mineradores estão recebendo UTXOs pequenos e de baixo valor em cada bloco que o P2Pool encontra, o que vem com o custo de condensar essas saídas mais tarde e/ou arcar com o custo de transações muito maiores quando vão gastar suas moedas por causa do vários UTXOs individuais com os quais eles acabam, em vez de um único ao retirar após um período de um pool convencional. Segundo: cada nova saída da base de moedas está ocupando um espaço de bloco que poderia ser consumido pelas transações de outras pessoas e gerando mais receita de taxas para o P2Pool. É uma perda dupla para os mineradores que participam do protocolo.

Esses dois problemas contribuíram para que o protocolo morresse lentamente e acabasse caindo em um estado de desuso. Por todas as indicações do meu melhor esforço para rastrear estatísticas precisas e recentes (muitos antigos exploradores de blocos que rastreiam o compartilhamento do pool de mineração foram desativados ao longo dos anos), parece que o último bloco minerado pelo P2Pool estava ativado 12 de fevereiro de 2019.

P2Pool com pagamentos de canal de pagamento

Em 2017, um mês após a ativação do SegWit, Chris Belcher fez um proposta melhorar a escalabilidade do P2Pool com o uso de canais de pagamento unidirecionais e um grupo de hubs que lidam com pagamentos aos mineradores.

O objetivo principal da proposta é abordar a questão das transações maiores de moedas que perdem o dinheiro dos mineradores de duas maneiras diferentes. Em um nível alto, a ideia é simplesmente pagar toda a transação da base de moedas para um hub com canais de pagamento abertos para os mineradores individuais e garantir que a capacidade de reivindicar os fundos da transação da base de moedas esteja atomicamente ligada aos mineradores sendo compensados. suas ações nos canais de pagamento.

Para atingir o objetivo de atomicidade entre a transação coinbase e os canais de pagamento para pagamentos, o script de saída da transação coinbase deve ser customizado. Na proposta de Belcher, ele está estruturado como um roteiro multi-filial com três condições de gastos:

• Um multisig de dois em dois. Chave um: o hub (Hc). Chave dois: mineiro que encontrou o bloco (Mc).
• Uma única chave e um hashlock. Chave: o cubo (H). Hashlock: um valor aleatório gerado pelo hub (X).
• Uma única chave e um timelock. Chave: o mineiro que encontrou o bloco (M). Timelock: um timelock relativo CSV de seis meses.

Qualquer uma dessas condições de gastos pode ser usada para desbloquear a saída da transação da base de moedas. Agora, vamos ver o script do canal de pagamento para os mineradores para que possamos ver como as duas coisas interagem:

• Um multisig de dois em dois. Chave um: o hub (Hc1). Chave dois: o mineiro (Mc1).
• Um multisig de dois em dois e um hashlock. Chave um: o hub (Hu1). Chave dois: o mineiro (Mu1). Hashlock: o valor aleatório gerado pelo hub usado na coinbase (X).

Agora, vamos ver como essas duas coisas interagem uma com a outra.

À medida que os mineradores estão produzindo compartilhamentos para adicionar ao sharechain, o hub monitora o progresso. Para cada compartilhamento, o hub atualiza o estado do canal com os mineradores que entregam um compartilhamento para pagá-los proporcionalmente à quantidade de trabalho que estão fazendo. No entanto, eles apenas fornecem uma assinatura para o segundo caminho de script que exige que a pré-imagem do hashlock seja gasta - isso garante que, por padrão, sem que o hub forneça uma assinatura para o primeiro caminho, eles não podem reivindicar esses fundos, a menos que o hub gaste a base de moedas saída por si só usando o caminho do script com o hashlock, o que exige que eles publiquem a pré-imagem.

Agora, eventualmente, um dos mineradores no P2Pool encontrará um bloco válido e o publicará na rede. Neste ponto, o hub pode atualizar todos os canais de pagamento com os mineradores e fornecer a assinatura para o primeiro caminho de script no canal, permitindo que cada minerador feche seu canal e colete as recompensas que ganhou quando quiser sem precisar do hashlock pré-imagem.

Nesse ponto, o minerador que encontrou o bloco assina o primeiro caminho de script na base de moedas, permitindo que o hub reivindique os fundos da base de moedas. Esse minerador recebe um pequeno bônus das recompensas de mineração para incentivá-lo a assinar cooperativamente. Mas lembre-se: se o minerador se recusar a cooperar, o hub pode simplesmente gastar sozinho usando o caminho de hashlock e revelar a pré-imagem, permitindo que todos os mineradores recebam sua parte justa da recompensa.

Isso só tem a desvantagem de forçar todos os canais a fecharem na cadeia, precisando ser reabertos para continuar a mineração. A última opção existe caso o operador do hub opte por interromper o processamento de pagamentos ou desapareça. Após seis meses, o minerador que encontrou o bloco pode reivindicar os fundos inteiramente para si mesmo se o hub não respondeu para cooperar ou gastou as moedas com o caminho do hashlock.

Isso deixa duas questões específicas em termos de modelo de ameaça com as melhorias propostas por Belcher. Decidir quais transações incluir em um bloco deixa espaço para variação em quanto da recompensa total do bloco é baseada no que os mineradores individuais escolhem incluir nos modelos de bloco que estão minerando.

Ao introduzir canais de pagamento, isso cria uma margem de erro, ou seja, a recompensa real do bloco minerado não é igual ao que um hub de mineração se compromete nos canais de pagamento aos mineradores. No caso de as estimativas de taxas reais serem menores do que a recompensa do bloco, o hub pode simplesmente atualizar os canais de pagamento usando o caminho de gasto cooperativo com o menor valor, e desde que eles não reivindiquem a saída da base de moedas com o caminho de hashlock, os mineradores não têm escolha a não ser aceitar o pagamento menor que corresponde ao que a recompensa de mineração realmente era.

No caso de a recompensa de mineração ser um pouco maior do que a estimativa, ainda é do interesse do hub atualizar os canais para os mineradores para refletir isso, pois os mineradores que o hub trata desonestamente podem simplesmente sair a qualquer momento. O único caso extremo em que pode fazer sentido para o hub desertar e manter a recompensa extra seria se alguém pagasse uma taxa de minerador anormalmente grande, mas, além dessa situação, é do interesse do hub e dos mineradores se ajustar a qualquer discrepância entre a estimativa de recompensa e a recompensa real do bloco.

A segunda questão é o fato de que o hub é um ponto central que pode ser DDoS e forçado a impedir o funcionamento do P2Pool. A proposta de Belcher envolve o uso de vários hubs e o envio de cada transação coinbase de diferentes blocos para diferentes hubs. No entanto, isso exige que os mineradores tenham canais abertos de todos os hubs que estão usando, o que, na estimativa de Belcher de um hub que precisa de 50 vezes a recompensa do bloco (cerca de 650 BTC) para fornecer liquidez aos mineradores, torna-se incrivelmente ineficiente em termos de capital.

Braidpool: Outra Iteração

Entrar Conjunto de tranças (aviso: o link é um download direto do PDF do GitHub). Braidpool é uma proposta de Bob McElrath e Kulpreet Singh baseada na proposta de Belcher usando canais de pagamento. Há duas grandes mudanças introduzidas que melhoram as questões pendentes deixadas com a proposta de Belcher.

A primeira é uma alteração na forma como os hubs e os mineradores se comunicam. Eles propõem que os mineradores atribuam um endereço Tor v3 a cada um dos compartilhamentos que eles transmitem para o pool. Dessa forma, o hub pode operar sem expor nenhum endpoint de rede suscetível a ataques DoS.

O operador do hub pode então se conectar aos mineradores para abrir e atualizar canais com eles, aliviando a necessidade de os mineradores usarem vários hubs para evitar um único ponto de ataque. Isso permite que um Braidpool opere com um único hub, tornando todo o sistema mais robusto e eficiente em termos de capital.

A segunda mudança é o uso de um gráfico acíclico direcionado (DAG) em vez de um sharechain. O problema com o sharechain era que, com a meta de tempo de compartilhamento de trinta segundos, a dificuldade necessária para as ações aumentava à medida que o pool crescia em tamanho, tornando-o mais difícil para mineradores menores. Usar um DAG como o Ethereum, onde não é um jogo de soma zero de um único compartilhamento entrando no sharechain e outros ficando órfãos, permite que os mineradores definam dinamicamente uma dificuldade para compartilhamentos que pode ser ajustada com base na taxa de hash que eles têm e como freqüentemente eles podem encontrar compartilhamentos com ele.

A estrutura do DAG inclui todos os que participaram dela entre os blocos reais de Bitcoin encontrados, distribuindo as recompensas proporcionalmente entre todos com base no trabalho que forneceram ao DAG. Isso resolve o problema de escala de variação para mineradores individuais à medida que os pools crescem.

Tirando essas duas mudanças, o restante da estrutura é exatamente como a proposta de Belcher, a base de moedas e os scripts dos canais são os mesmos.

Considerações Finais

Alguns leitores podem se perguntar por que Betterhash não foi abordado neste artigo. Ao descentralizar a seleção de transações para inclusão em um bloco, ela não descentraliza totalmente todas as funções do pool - mais importante, a natureza de custódia dos pools que lidam com fundos. Isso deixa os mineradores abertos à coerção por meio de recusas de pagamento de fundos se o minerador estiver selecionando transações que o pool não aprova. Portanto, eu não o consideraria um pool de mineração descentralizado, embora melhore marginalmente a situação em um ambiente hostil, mas não totalmente adversário.

Este artigo foi centrado no P2Pool e propôs iterações para melhorar suas limitações de dimensionamento. Para não escrever um livro inteiro, não toquei em outros projetos existentes ou potenciais. Assim que eu conseguir chegar a isso, pretendo escrever um artigo de acompanhamento, abordando outros mecanismos para descentralizar os pools de mineração.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou Bitcoin Magazine.

• Coinsmart. A melhor troca de Bitcoin e criptografia da Europa.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. ACESSO LIVRE.
• CryptoHawk. Radar Altcoin. Teste grátis.
• Fonte: https://bitcoinmagazine.com/technical/p2pool-bitcoin-mining-decentralization