Blockchain e Bitcoin – Parte V: Entendendo o bitcoin – o registro distribuído e a ausência de um terceiro confiável

Blockchain e Bitcoin – Parte V: Entendendo o bitcoin – o registro distribuído e a ausência de um terceiro confiável

Dr. Augusto Marcacini – Colunista Crypto ID

Por Augusto Marcacini

Nos dois textos anteriores desta série, apresentei dois detalhes técnicos sobre o funcionamento do bitcoin, comentando como são feitas cada uma das transações, utilizando assinaturas digitais, e como seu registro é encadeado por meio de uma outra função criptográfica, a função hash.

Há substancial segurança, portanto, nessas operações, mas também se pode dizer que elas não seriam, isoladamente, uma novidade tão inesperada, pois, de algum modo aproximado, isso é o que faz o sistema financeiro, ao atuar como uma terceira parte de confiança e manter uma contabilidade eletrônica dos depósitos de seus correntistas.

Ao final do texto anterior, acrescentei o terceiro e mais desconcertante aspecto do funcionamento do bitcoin: não há um terceiro sujeito de confiança que opere o sistema. Todos os registros contábeis da criptomoeda estão distribuídos entre todos os participantes de uma grande rede, aberta a qualquer um que instale e execute o software correspondente. Diante disso, duas dúvidas podem surgir: como preservar a segurança de um sistema assim anárquico e por que alguém desejaria participar disso e colaborar com a manutenção da contabilidade das transações em bitcoins?

Aqui, podemos dizer que a solução proposta por Satoshi Nakamoto não se assenta somente em engenharia de software, mas, de algum modo, também em engenharia social. O estímulo para colaborar provém da perspectiva de ser remunerado, evidentemente, em bitcoins. Por outro lado, outras operações criptográficas suportam a segurança do modelo distribuído.

Assim, prosseguindo na explicação sobre o funcionamento do bitcoin, podemos partir das informações já apresentadas nos textos anteriores.  A diferença é que aquelas tarefas que, no exemplo dado, eram por mim executadas, isto é, receber as “ordens de pagamento”, realizar os créditos e débitos correspondentes e manter um registro eletrônico encadeado, cuja cronologia possa ser matematicamente demonstrada, serão executadas em um modelo de processamento distribuído, em que todos e qualquer um podem participar.

Cada participante que ingressa no sistema mantém toda a contabilidade e vai, em um trabalho redundante com o dos demais, formando os próximos blocos de transações a serem encadeados. Cada nova transação é recebida por todos esses pontos, que conferem as respectivas assinaturas e, então, formam um novo bloco com certo número de transferências. Calcula-se o “resumo” dessas transações, com uso da função hash, chegando-se a um “resumo” geral que representa a totalidade das transações daquele bloco.

Como calcular Hash

Para calcular, finalmente, o hash que encerra esse bloco, toma-se como parâmetro, como vimos na quarta parte desta série, o “resumo” do bloco anterior, o “resumo” de todas as transações novas e – acrescentemos finalmente esse importante detalhe – um número que será encontrado após uma difícil tarefa, cuja execução requer uma grande capacidade de processamento.

Encontrar esse número é o que se chama “proof-of-work”, ou prova de trabalho, e nisso reside mais um detalhe da segurança da escrituração distribuída dos bitcoins. A prova de trabalho é uma espécie de desafio, inserido no modelo para propositalmente tornar bastante difícil o fechamento do bloco e, consequentemente, muitíssimo mais difícil qualquer tentativa de se reescrever os blocos anteriores da cadeia.

O risco que se quer combater com isso é o de que alguém apague ou insira registros retroativos na cadeia, isto é, uma fraude comparável, no mundo físico, a jogar fora o livro-caixa e refazer seus lançamentos, com as modificações desejadas. Note-se, no caso do bitcoin, que uma vez que todas as transações precisam estar assinadas digitalmente com a chave privada correspondente à conta debitada, o risco não é o de se retirar valores de uma conta, pois isso só pode ser feito diante de uma “ordem de pagamento” validamente assinada. O risco que se quer evitar, com a prova de trabalho, é o de que alguém cancele ou retarde pagamentos feitos anteriormente, retirando ou inserindo registros e, com isso, pratique o “double spending”, isto é, gaste duas vezes o mesmo dinheiro (embora só uma das transações poderá ser definitivamente escriturada, ficando o outro credor a ver navios…)

Por exemplo: Caio fez, nos textos anteriores desta série, um pagamento de dois bitcoins para Tício. Esse pagamento não teria sido aceito pela contabilidade da blockchain se Caio não tivesse ao menos esse valor como saldo. Imaginemos que, vendo os dois bitcoins creditados em sua conta, Tício entregou algumas muitas toneladas de salsichas, que ele produz. Mas e se Caio conseguisse, uma vez recebida a mercadoria, apagar dos registros, retroativamente, a transferência que fez a Tício? E, ato contínuo, ele transfere os dois bitcoins, ainda considerados em sua conta, para Mévio, de modo que o saldo fosse zerado. Não sendo possível gastar duas vezes os mesmos valores, o pagamento a Tício, se considerado posterior, seria recusado, mas Caio já levou embora as salsichas Como fazer com que, em um processamento distribuído, tal fraude não venha a ocorrer?

A prova de trabalho consiste no seguinte desafio: o hash que fecha cada bloco deve ter uma característica pré-definida. Digamos que, dos 85 algarismos decimais que compõem o “resumo”, seja estabelecido que os cinco, seis, ou dez primeiros devam ser zero. Se o hash fosse calculado somente sobre a concatenação do “resumo” do bloco anterior com o “resumo” geral das novas transações, esse valor seria exato e invariável, pois é o resultado de uma operação matemática calculada a partir dessas variáveis fixas. É para isso que se insere um número a mais, como falado pouco acima. Esse é um número qualquer, que precisa ser encontrado como resposta ao desafio, de tal modo que, agregado aos dois “resumos” anteriores, produza um “resumo” final – que fecha o bloco – com o predefinido número de zeros iniciais.

Como as funções hash são funções matemáticas sem retorno, cujas propriedades comentei no terceiro artigo desta série, não há outra maneira de se cumprir essa prova de trabalho senão com força bruta, isto é, testar sequencialmente uma quantidade gigantesca de opções, como valor desse número extra, calculando-se o “resumo” com cada uma delas, até que seja encontrado um “resumo” iniciado pelo desejado número de zeros. Assim, o fechamento de cada bloco exige um esforço significativo, em termos de capacidade de processamento informático.

Para se tentar fraudar um registro passado, portanto, alguém teria que empregar o equivalente a toda a capacidade de processamento já utilizada pelo sistema desde que esse registro foi feito, o que, como veremos a seguir, é uma tarefa estatisticamente intratável.

Em síntese, as coisas funcionam da seguinte maneira

Para se fazer uma transferência, esta é assinada com uma chave privada, que corresponde à chave pública em cuja “titularidade” estão escriturados alguns bitcoins; essa ordem assinada indica o valor a transferir e a chave pública destinatária, para a qual os valores serão atribuídos. A ordem é distribuída entre todos os “nós” da rede ponto a ponto, isto é, entre todos os participantes que estão mantendo a contabilidade dos bitcoins. Cada um desses nós recebe todas as ordens, fecha mais um bloco, e começa a tentar calcular um “resumo” com, digamos, dez zeros iniciais, mediante a inserção de uma variável arbitrária, que deve ser “encontrada”. Para superar esse desafio, será necessário tentar seguidamente uma imensa quantidade de diferentes números, até que seja encontrado um “resumo” que comece com dez zeros.

Uma vez que um desses participantes resolva o desafio, ele transmite o resultado para todos os demais pontos e estes, conferindo o “resumo” e constatando que o desafio foi corretamente solucionado, acrescentam consensualmente esse novo bloco na cadeia e passam a trabalhar com o próximo bloco. E o participante que solucionou o problema recebe um prêmio, que no início era igual a 50 bitcoins, mas o sistema foi originalmente programado para ir aos poucos decaindo esse valor, estando hoje em 12,5 unidades da criptomoeda. A obtenção desse prêmio é o que se tem chamado de “mineração” de bitcoins.

O esforço computacional empregado pelo participante vencedor é comparado a uma espécie de garimpo, que encontra e retira ouro da natureza e com ele cunha novas moedas. Juridicamente falando, isso pode ser comparável a uma aquisição originária da propriedade, pois esses valores não foram recebidos de ninguém; ou também podemos comparar à emissão de mais moeda pelos governos. É essa “mineração” que faz com que a base monetária do bitcoin venha crescendo paulatinamente, desde que o sistema foi posto em funcionamento, em janeiro de 2009.

Tal prêmio é o incentivo que o sistema confere a quem está trabalhando por ele, na manutenção da escrituração contábil dos bitcoins. Além dos bitcoins “minerados”, o vencedor do desafio também credita para si o valor das taxas, que são previstas no modelo e descontadas de quem faz cada transferência.

Mais do que um sofisticado sistema baseado em redes de computadores e criptografia, há um bom tanto de engenharia social envolvida nesse modelo. Os “mineradores” de bitcoin estabelecem um consenso em utilizar a mesma versão do software, versão esta que está programada para automaticamente realizar todas as operações que descrevi neste e nos textos anteriores desta série. Uma vez que uma das partes encontre o resultado do desafio, ele é reconhecido por todos os demais como o vencedor daquele bloco, estando apto a creditar para si o valor das taxas de todas as transferências nele escrituradas, mais as moedas “mineradas”.

O modelo ainda prevê correção de falhas de rede, caso, por exemplo, as conexões ponto-a-ponto não permitam que todas as mesmas transações sejam igualmente distribuídas a todos os “nós” participantes. Imaginemos que, de cem transações feitas nos últimos dez minutos, alguns dos participantes receberam apenas 99, ou ainda menos. Não importa. Se um destes últimos participantes fechar o bloco, aquela transação que não lhe chegou a tempo será incluída no próximo bloco, por ele mesmo ou pelos demais. Assim é resolvido o problema decorrente de inevitáveis atrasos nas comunicações e na desigual distribuição das transações por toda a rede.

Mais grave seria se esse atraso na rede ocorresse no momento de comunicar aos demais participantes que um bloco foi fechado. E se, por exemplo, um participante resolver o desafio de um bloco mas, em frações de segundo, outro participante também lograr resolvê-lo? A solução para isso também é prevista. Se, por exemplo, o bloco de número 100 da cadeia for simultaneamente resolvido por dois diferentes participantes, cada um deles distribuirá aos demais o bloco que fechou, sendo possível que alguns destes recebam o primeiro e outros, o segundo. Neste caso, cada “grupo” desses terá um bloco 100 diferente, mas continuará normalmente a calcular o próximo bloco. Quando um dos participantes fechar o bloco 101 em primeiro lugar e distribui-lo pela rede, essa será a bifurcação dos registros que prevalecerá. O grupo que trabalhava com a outra cadeia, ao receber o novo bloco 101, apagará o seu bloco 100, substituindo-o pelo bloco 100 da outra cadeia, que foi “vencedora”. Se ainda prevalecer duas soluções simultâneas para o bloco 101, distribuídas entre diferentes participantes, a bifurcação continua até a solução do bloco 102, e assim sucessivamente, não sendo estatisticamente provável que a divergência perdure por muito tempo. Por esta razão, considera-se que uma transação está consolidada tão somente quando o bloco em que está registrada já foi superado por mais dois ou três blocos seguintes, ou mais, caso se queira níveis maiores de certeza.

Seria possível que alguém desrespeitasse esse consenso e, com isso, cometesse a fraude de inserir ou retirar registros de forma retroativa, como no exemplo da venda de salsichas que apresentei linhas acima? Em tese, sim. A segurança contra isso é acreditar que a maioria dos participantes não o faria. Todo o sistema baseia-se na honestidade da maioria dos participantes, maioria essa que é medida não pela quantidade de indivíduos, mas pela quantidade de poder de processamento dedicada a manter viva a blockchain. Desde os primeiros textos discutidos no fórum de criptografia, essa era a proposta de Satoshi Nakamoto para lidar com os problemas de “double spending”, ou outras tentativas de fraude em uma escrituração distribuída.

Para fraudar o sistema, o fraudador precisaria ter poder de processamento suficiente para bater todo o restante dos participantes, de modo que reconstrua cadeias anteriores, até a cadeia presente, em velocidade maior do que aquela com que os blocos são constantemente gerados.

A fraude a combater seria a seguinte: uma vez feito um pagamento de 50 bitcoins, inserido, por exemplo, no registro 100, e após recebida a contrapartida (pagamento em moedas oficiais, ou entrega definitiva de outro produto ou serviço) o pagante tentaria retirar aquela transferência da escrituração, para tentar gastar o mesmo saldo noutra transação. Se a outra parte esperou mais duas ou três transações para entregar sua contraprestação, a blockchain já estaria, portanto, no bloco 103. Para ter sucesso, o fraudador precisará recalcular o desafio do bloco 100, excluída a transferência que fez, e depois recalcular todos os blocos seguintes. Lembremos que, retirada uma transação, o “resumo” do bloco 100 será diferente e, consequentemente, todos os “resumos” seguintes e seus desafios terão que ser novamente calculados, uma vez que o resumo do bloco 100 integra os registros do bloco 101 e assim por diante.

Mas, enquanto o fraudador calcula uma cadeia paralela, sem o seu pagamento, todo o restante da rede também está operando e inserindo novos blocos. O fraudador haveria de ter mais poder de processamento do que todo o resto da rede, para conseguir fechar os blocos mais rapidamente, alcançar e superar o número de blocos que estão nos registros “corretos”; quando, então, o criminoso conseguisse produzir um bloco mais adiantado e o distribuísse na rede, todo o sistema descartaria a cadeia com que trabalhava e adotaria a cadeia do fraudador. Mas isso só será factível se empregado um poder de processamento maior do que a soma do de todos os demais participantes.

Mas, neste caso, alguém que acaso controlasse tal poder de processamento iria empregá-lo para tão somente apagar um ou alguns pagamentos próprios e imediatamente transferi-los para outra conta? É improvável que a relação custo-benefício lhe seja vantajosa. Ademais, quem detém tal poder de processamento, possivelmente ganharia muito mais “minerando” bitcoins honestamente. E, sendo titular de ativos em bitcoins, por que alguém iria utilizar tamanho poder de processamento para desacreditar a escrituração da moeda?

Há, como dito, também uma certa base social que sustenta a segurança do bitcoin. Supõe-se que, se não por sincera honestidade, ao menos por interesse a maioria do poder de processamento do sistema seguiria as regras do jogo, que estão fixadas na programação do software livremente distribuído.

Compreendidos os aspectos técnicos de funcionamento da criptomoeda, continuaremos no próximo texto comentando outros temas relevantes sobre o bitcoin.

*Sobre Dr. Augusto Marcacini

– Advogado em São Paulo desde 1988, atuante nas áreas civil e empresarial, especialmente contencioso civil, contratos e tecnologia.

– Sócio do escritório Marcacini e Mietto Advogados desde 1992.

– Bacharel (1987), Mestre (1993), Doutor (1999) e Livre-docente (2011) em Direito pela Faculdade de Direito da Universidade de São Paulo.

– Foi professor no Mestrado em Direito da Sociedade da Informação da UniFMU entre 2011 a 2018, lecionando as disciplinas “Efetividade da Jurisdição na Sociedade da Informação” e “Informatização Processual, Provas Digitais e a Segurança da Informação”.

– Professor de Direito Processual Civil desde 1988, em cursos de graduação e pós-graduação.

– Vice-Presidente da Comissão de Direito Processual Civil, Membro Consultor da Comissão de Informática Jurídica e Membro da Comissão de Ciência e Tecnologia da OAB-SP (triênios: 2013-2015 e 2016-2018)

– Ex-Presidente da Comissão de Informática Jurídica e da Comissão da Sociedade Digital da OAB-SP (triênios 2004-2006, 2007-2009 e 2010-2012) e Ex-Membro da Comissão de Tecnologia da Informação do Conselho Federal da OAB (triênio 2004-2006).

– Autor de diversos livros e artigos, destacando-se na área de direito e tecnologia: “O documento eletrônico como meio de prova” (artigo, 1998), “Direito e Informática: uma abordagem jurídica sobre a criptografia” (livro, 2002), “Direito em Bits” (coletânea de artigos em coautoria, 2004), “Processo e Tecnologia: garantias processuais, efetividade e a informatização processual” (livro, 2013) e “Direito e Tecnologia”, (livro, 2014).

– Palestrante e conferencista.

– Colunista e membro do conselho editorial do Crypto ID.