«Eu sou bastante paranóico, gosto de seguir o lema: mais vale prevenir do que remediar. Por isso geralmente aguardo por 6 confirmações e tem que incluir 3 mineradores diferentes.»
Esta afirmação foi feita por mim, no texto, na parte dos ataques de 51%, mas gerou alguns comentários e pedidos de esclarecimentos, acho que merece uma explicação mais detalhada, vamos a ela. A parte que gerou mais dúvidas/curiosidade foi o porquê de eu aguardar sempre por 3 confirmações de mineradoras diferentes. Mais concretamente, a Foundry e a AntPool têm que estar incluídas nesse lote de 3.
Mas antes de explicar o porquê, é necessário contextualizar.
Blockchain
A priori, é necessário compreender como é a arquitetura da blockchain do Bitcoin.
Sempre que um minerador “encontra” um bloco, envia para a rede de nós(nodes), cada nó, individualmente vai conferir a veracidade dos dados e se cumpre com todas as regras de consensos, em caso positivo, o bloco é adicionado na blockchain.
O minerar um do bloco é algo muito variável, tanto pode demorar alguns segundos, como pode demorar mais que uma hora, na mineração existe um factor de sorte, existe alguma aleatoriedade. Mas em média os blocos são adicionados a cada 10 minutos.
Por vezes, dois mineradores “encontram” o bloco (no exemplo em baixo, o 853185) quase em simultâneo, cada um comunica com os seus nós. Assim, uns nós da rede vão receber primeiro a informação do minerador A (AntPool) e outros nós receber do minerador B (Foundry USA), gerando duas linhas de tempo, ou seja, existe um fork/bifurcação na cadeia. Os forks é algo muito recorrente, acontece diariamente, é completamente normal, podemos observar aqui e em tempo real.
A bifurcação apenas acontece porque a blockchain é descentralizada, não existe um órgão central que determina quem foi o primeiro.
Como existem duas linhas de tempo, é necessário fazer um “desempate”, porque não podem existir duas linhas de tempo. Assim a primeira linha de tempo a encontrar o seguinte bloco (853186), ganha, neste exemplo foi a Foundry:
Os nós que seguiam a linha da AntPoll, são obrigados a reorganizar a sua linha de tempo e passam a seguir a linha da Foundry. O bloco 853185 que a AntPool descobriu é eliminado, é chamado de órfão, assim as transações que estavam no bloco órfão são “eliminadas”.
Como a reorganização dos blocos é algo recorrente na blockchain do Bitcoin, logo uma transação só deve ser considerada imutável após vários blocos/confirmações. Algumas empresas aguardam por 3 confirmações, mas é aconselhável esperar por 6 confirmações, é praticamente impossível uma reorganização tão longa. As confirmações são uma medida de segurança.
Ataque 51%
Quanto mais confirmações exigir, mais blocos serão necessários reorganizar. Quanto mais longa a reorganização, mais caro e complexo é o ataque e reduz a probabilidade de sucesso.
Vamos a um exemplo, de um possível ataque de duplo gasto a uma exchange, que exige apenas 3 confirmações:
O minerador que está a realizar um ataque, sempre que encontra um bloco não informa o restante da rede, é como se tivesse a minerar secretamente, passando a existir duas linhas de tempo paralelas, a oficial e a do atacante.
O atacante terá que fazer um gasto duplo, ou seja, terá que enviar o mesmo UTXO para as duas linhas de tempo, com destinos diferentes.
- Uma transação com um output para uma exchange, será incluída no bloco 1001, linha de tempo oficial.
- A outra transação com um endereço seu no output, será incluída no bloco secreto 1001.
O atacante terá que continuar a minerar, sem nunca informar o restante da rede.
Como a exchange aguarda apenas por 3 confirmação, quando o bloco oficial 1003 for adicionado à linha de tempo oficial, o valor da transação fica disponível para o atacante na exchange, retirando-o de imediato da exchange.
Como o valor já não está na exchange, quando o bloco 1004 secreto for encontrado, o atacante envia a informação para toda a rede, todos os nós vão receber essas informações, mas é obrigatório o bloco secreto 1004 ser descoberto primeiro que o oficial.
Como o bloco secreto foi descoberto primeiro, toda rede terá que reorganizar-se para a linha do tempo, passando a seguir a linha de tempo do atacante. Com a reorganização, 3 blocos ficam órfãos, logo as transmissão não são válidas, assim a transmissão que o atacante efetuou para exchange não conta, ficando no seu lugar, a transação para si mesmo. A exchange é lesada, o ataque fica com o dobro do valor, um duplo gasto.
Mas o ataque só terá sucesso, se a linha do tempo do atacante for mais rápida que o restante da rede. Para acontecer, o atacante terá que ter um hashrate superior aos restante dos mineradores.
Viés de sobrevivência
Agora vamos a uma história da 2ª Grande Guerra Mundial:
Abraham Wald (matemático hungaro) fez parte do Grupo de Pesquisa Estatística. O grupo recebeu a tarefa de decidir onde aplicar fuselagem extra para proteger os aviões dos aliados contra os ataques dos nazistas. Para isso, analisaram a localização dos furos de bala nos aviões. Poderia-se chegar a conclusão de que seria melhor blindar essas regiões, já que elas recebem mais tiros. No entanto, Wald apontou que havia um viés de sobrevivência nessa questão. Os dados se tratavam apenas dos aviões que retornavam à base, e nada se sabia sobre aqueles que eram derrubados.
Supondo que a distribuição de tiros em todos os aviões seria aleatória (ou seja, os nazistas não miravam especificamente na asa nem no motor nem na fuselagem), o que os dados indicavam na verdade era quais aviões conseguiam voltar à base. Concluiu, então, que os aviões que levavam tiros na cabine do piloto ou no motor não sobreviviam, e por isso era nessas regiões que a blindagem extra deveria ser aplicada. – Wikipédia
Conclusão
O que tem em comum entre o minerar em segredo e uma história da segunda guerra mundial, é simples.
A segurança da mineração do Bitcoin é muito similar aos aviões na guerra, o reforço da blindagem não é onde os aviões levaram os tiros, mas sim, onde não levaram tiros. Se Foundry e a AntPool estão a encontrar blocos, o risco de estarem a efectuar um ataque é nula. Pode haver algum risco, quando uma das duas grandes pools, estão um longo período sem encontrar blocos, ou estão com muito azar ou podem estar a tentar realizar um ataque. Apesar de tudo, é muito mais provável estarem com azar.
Atualmente, já existem ferramentas que monitoram a rede, para encontrar anomalias, é possível saber a linha de tempo que a maioria das pools estão a seguir, incluindo a AntPool, apenas os dados da Foundry não são públicos, nesta sim é necessário um maior cuidado. Mas eu mantenho velhos hábitos.
Hoje em dia, com a atual distribuição de hashrate, se as duas grandes pools estiverem a encontrar blocos normalmente, é praticamente impossível, existir um 3⁰ player conseguir realizar um ataque de 51% ao Bitcoin.
Por esse motivo, por motivos de segurança eu gosto de esperar por 6 confirmações, estas devem ser feitas, pelo menos, por 3 pools diferentes, incluindo sempre a Foundry e a AntPool.
Talvez seja excessiva esta preocupação, mas eu sou paranóico, prefiro ser cauteloso, do que lamentar depois.
Dont’t Trust, Verify!