Cortersia de: Radar BTC

Nesta semana, a Binance amargou seu primeiro hack com perdas de fundos sofrido até então — pelo menos assumido publicamente — e trouxe à tona um debate que até então era abafado e até mesmo ridicularizado dentre os maximalistas: o de um block-reorg para reversão de roubo de fundos.

A ideia em si não é nova, e já aconteceu com o Bitcoin anteriormente¹, e é também a razão de existirem Ethereum e Ethereum Classic².

Muito fora especulado acerca de como poderiam recuperar fundos, e houveram as mais diversas sugestões, umas mais e outras menos coerentes.

A “solução” mais “óbvia” e espalhada pelas redes sociais foi a de uma possível “parceria” entre a exchange e pools de mineração, para que estas voltassem o estado da rede até uma altura de blocoanterior ao roubo dos fundos, e assim continuar a minerar dali novamente. 

Parece, à primeira vista, uma solução genial, afinal, o entendimento geral é de que o consenso da rede vem unicamente de mineradores através de sua atuação por meio do Proof-of-Work, mas a questão é mais complexa.

Os mineradores não podem simplesmente voltar a um estado anterior da rede e retomar a mineração dali. Existem riscos envolvidos, principalmente financeiros. 

Tal sugestão, caso colocada em prática, levaria a uma catástrofe da rede, não apenas em perda de valor, conforme o próprio CEO da exchange assumiu num tweet:

Todavia, para entender uma reorganização de blocos e suas possíveis consequências para a rede, é preciso primeiro entender de onde vem o consenso desta, e como os agentes envolvidos atuam, de acordo com o protocolo.

Bitcoin, consenso e a soberania dos registros

Os agentes ativos de modificação e validação primária do estado da rede são os mineradores.

Mineradores atuam para dar seguridade à rede com uma produção de blocos com tempo médio de 10 minutos, com o objetivo de proteger a rede de possíveis ataques de spam com geração contínua de blocos, e permitir que a informação tenha tempo suficiente para que se espalhe aos nodes participantes.

Estes também são o primeiro filtro validador das transações que são transmitidas para a rede.

Existem também agentes passivos, que são os full nodes, que decidem a posterior validez das informações de acordo com as regras de consenso embutidas em seus clientes, conforme o protocolo dita.

Isto evita, por exemplo, que mineradores emitam um bloco que contenham uma transação com assinatura inválida.

Por mais improvável que seja que os mineradores façam algo do tipo, não é impossível, e caso ocorresse, os full nodes rejeitariam tal bloco, e o minerador perderia a recompensa do bloco.

Conclui-se, então, que os participantes da rede trabalham rumo ao consenso de acordo com seus respectivos papéis, com mineradores incentivados visando recompensas e agindo conforme o protocolo manda, e full nodes verificando e reiterando a validade das transações emitidas em cada bloco minerado.

Ou seja, não são somente mineradores que mandam na parada. 

Apesar do protocolo definir que os full nodes devem seguir a cadeia de blocos mais longa, mineradores não podem simplesmente redirecionar seu poder de mineração para uma cadeia de blocos adulterada, pois ainda assim os full nodes guardam informações sobre a rede, e podem decidir qual cadeia de blocos querem seguir.

Os registros que os full nodes guardam são a principal arma de agentes passivos contra uma adulteração do estado global da rede.

O passo-a-passo de uma reorganização de blocos

Apesar de parecerem eventos ocorridos de maneira arbitrária, reorganizações de blocos são mais comuns do que se imagina. É possível que duas cadeias de blocos diferentes possuam a mesma altura de bloco, e ainda assim mantenham a validade destes, mas depende de qual cadeia tomará a frente primeiro, e qual será aceita pela maioria da rede.

O protocolo do Bitcoin define uma metodologia de reorganização de blocos em casos corriqueiros como este, para que não ocorra um hard fork de registros da rede.

Quando isto ocorre, os full nodes que armazenam as informações da cadeia “perdedora” simplesmente descartam os blocos, que continuam válidos, mas se tornam a partir dali, obsoletos (comumente conhecidos de maneira errônea como blocos órfãos).

As transações contidas nestes blocos obsoletos voltam à mempool para serem reincluídas num bloco minerado posteriormente, e as recompensas e taxas de transação designadas aos mineradores destes blocos descartados, são perdidas. 

rollback bitcoin
Neste cenário, o “segundo bloco 2” é o bloco obsoleto, e a cadeia de blocos mais longa sobressalente fora prosseguida de modo a incluir os blocos de número 3 e 4 a partir do “primeiro bloco 2”

O roubo dos fundos foi executado na transação e8b406091959700dbffcff30a60b190133721e5c39e89bb5fe23c5a554ab05eae foi incluída no bloco de número 575013.

Para uma recuperação dos fundos, a Binance deveria encontrar um meio de convencer mineradores a voltarem a minerar a partir do bloco 575012 ou anteriores, tendo em vista que nestes blocos a transação ainda não havia sido incluída num bloco, e a Binance ainda detinha controle dos fundos. 

Além de convencer os mineradores a voltarem a mineração a uma altura anterior, deveriam encontrar um meio de convencer também os full nodes a aceitarem a reversão, o que seria praticamente impossível. É também uma corrida contra o tempo.

Voltar a rede a um estado anterior acarretaria em uma catástrofe em efeito cascata, pois isto implicaria em reverter todas as transações posteriores, levando a plataformas que já efetuaram os registros de depósitos de seus clientes a desfazerem a compensação das transações, levando a uma inconsistência de informações em seus bancos de dados.

Quem não possuísse um protocolo de rollback, estaria suscetível a ataques de double spending.

Para piorar a situação, existem cada vez menos incentivos para que mineradores voltem a minerar a partir de um estado anterior, tendo em vista que a Binance deveria abrir mão de parte dos fundos roubados por meio de uma grande taxa de transação para premiar aquele que tivesse coragem o suficiente de tentar a sorte de minerar numa altura passada e ainda ir contra o consenso do restante da rede.

Para simplificar o cenário, vamos imaginar que um único minerador seja o responsável por produzir todos os outros blocos após o hack. Assumiremos também uma recompensa de bloco de 12.5 bitcoins, sem considerar fees de transação, e desconsiderando um contra-ataque do hacker, pois este poderia também tentar “subornar” mineradores a manterem a mineração na cadeia mais longa. 

Na prática, a cada bloco que se passa, a Binance deveria oferecer 12.5 bitcoins a mais como recompensa para uma tentativa de block-reorg. Existiria um ponto onde não haveria mais incentivos suficientes para tentar este método como meio de recuperação de fundos.

Foram pouco mais de 7000 bitcoins roubados, e com uma recompensa de bloco de 12.5 bitcoins, passados 560 blocos já não haveria vantagem alguma em tentar reorganizar a cadeia (pois 560 x 12.5 = 7000), ou seja, a partir do momento em que o bloco 575573 fosse minerado, acabariam os recursos disponíveis para um possível block-reorg.

No momento da publicação deste artigo, a Binance deveria abrir mão de pelo menos 3400 bitcoins como forma de recompensar um minerador que se dispusesse a fazer esta reorganização de blocos.

Conclusão

Tentar um block-reorg seria muito danoso à rede do Bitcoin. Isto colocaria mineradores contra full nodes e empresas que fornecem serviços baseados que envolvam Bitcoin. Estas últimas teriam muito mais trabalho e correriam o risco de um prejuízo ainda maior, levando-as a não apoiarem tal façanha.

Engana-se quem achou num primeiro momento que bastaria ligar pro Jihan Wu. Seria preciso ligar também para inúmeros outros players do mercado, e a cada ligação, um bloco se passaria.

Concluímos também que não são apenas os mineradores que ditam as regras na rede do Bitcoin, ou seja, o consenso não depende apenas destes agentes, e não somos reféns de mineradores, como se prega por aí.

O consenso vem de uma atuação harmoniosa da rede como um todo, pois full nodes possuem autoridade suficiente para escolher qual rede desejam participar.

Não fosse por isso, não haveriam disputas emblemáticas noutros tópicos que abordam mudanças no protocolo, a exemplo do aumento do blocksize.

P.S.: Tentar reorganizar a cadeia de blocos pode ser considerada uma forma mais bonita de nomear um 51% attack