F 2 corpo finito com dois elementos
8.6 Análise de Π cmm rec e sua Implementação Bitcoin
rec e sua ImplementaçãoBitcoin
O protocolo Πcmmrec é uma proposta para se alcançar justiça na reconstrução de um segredo com uma quantidade constante de rodadas. Ele se baseia na funcionalidade fcmm, que tem
objetivo similar ao da fcr utilizada pela construção escada. A diferença essencial entre essas
funcionalidades é que fcmmlida com depósitos de vários participantes simultaneamente, ao passo
que fcrlida com depósitos de apenas dois participantes por vez.
Apesar de fcmm ter uma quantidade constante de rodadas, sua implementação Πcmm
baseada no Bitcoin é conduzida em O(m) rodadas. Isso ocorre porque, além das rodadas necessárias para a realização das etapas definidas em fcmm, precisamos das chamadas rodadas
preliminaresem Πcmm. Essas rodadas servem para coordenar os participantes na criação das
transações, de modo a tornar factíveis as ações previstas para a rodada τi0(i> 0) sempre que as previstas para a rodada τi0−1tiverem sido tomadas.
Contrastando com as rodadas preliminares temos as “rodadas Bitcoin”. Como o nome sugere, é durante essas rodadas que os participantes de Πcmm interagem com o Bitcoin e,
em especial, publicam transações na blockchain. Elas ajudam a estabelecer uma ordem de publicação, de modo que uma transação pode garantidamente ser publicada na rodada τi(i> 0)
se a rodada τi−1 tiver transcorrido sem problemas. No entanto, mais do que essa ordenação, as
rodadas Bitcoin garantem a resistência de Πcmm contra ataques de gasto-duplo. De fato, nós
já argumentamos que essas rodadas, medidas em blocos, precisam ser longas o suficiente para comportar uma quantidade segura de confirmações (Tseg).
A diferença essencial entre as rodadas preliminares e as Bitcoin é que as preliminares não precisam ser medidas em blocos. Isso é essencial para a nossa argumentação de que Πcmme,
consequentemente, Πcmmrec são escaláveis. Esperamos que as rodadas preliminares sejam muito mais curtas que as Bitcoin. De fato, o tamanho mínimo de uma rodada Bitcoin, de modo a comportar as 6 confirmações recomendadas, é de 6 blocos, ou seja, de 1 hora em média. Enquanto isso, uma rodada preliminar deve apenas ser longa o suficiente para permitir a transmissão de transações e o cálculo de algumas funções criptográficas, como as relacionadas a assinaturas
9De fato, existem O(m) rodadas preliminares e O(1) rodadas Bitcoin. No entanto, como já argumentamos
8.6. ANÁLISE DE ΠCMMREC E SUA IMPLEMENTAÇÃO BITCOIN 168
digitais. Por isso, o tempo total de execução de Πcmm deve ser dominado por suas 3 rodadas
Bitcoin, mesmo para valores grandes de m.
A escalabilidade de Πcmm, em relação ao tempo de execução, segue principalmente
do fato de que a quantidade de rodadas Bitcoin necessárias não depende de m. Além disso, ressaltamos que, embora existam O(m) rodadas preliminares, cada participante só toma parte em até 4 delas: 1 para criar Txndepi , 1 para ajudar a criar Txncompe 2 para criar Txnpeni→ j.
Outra característica importante de Πcmmrec é sua simetria em relação ao investimento inicial feito pelos participantes. Nele, é necessário que todos façam um depósito de(m− 1) · q moedas no início da execução. Isso contrasta com a construção escada em que, por exemplo, P1investe
somente q moedas enquanto Pminveste(m− 1) · q e os demais, um valor intermediário. Usamos
essa observação também para ressaltar que o nosso investimento inicial, além de simétrico, é compatível com os da construção escada. Isso é importante porque, embora o investimento inicial seja imprescindível para se alcançar justiça monetária, para os participantes honestos ele funciona essencialmente como uma “barreira” inicial. Isso porque eles precisam juntar moedas apenas para, no final, recebê-las de volta. Nosso protocolo, em relação à construção escada, não aumenta essa barreira.
O investimento inicial exigido por Πcmmrec também tem impacto sobre sua escalabilidade, uma vez que, para um número grande de participantes, tal investimento pode se tornar proibitivo. Seu valor absoluto, no entanto, pode ser regulado pelo parâmetro q de multa por aborto. De maneira geral, o valor do investimento inicial tem que acompanhar a “importância” do resultado da computação para fazer com que comportamentos maliciosos não valham a pena. Sob essa perspectiva, a quantidade de participantes pode ser um indicativo dessa importância e, portanto, sua influência no valor do investimento pode ser justificável.
Como ponto negativo de Πcmm ressaltamos o tamanho da transação Txncomp, que é da
ordem de O(m2). Essa é uma característica ruim porque o protocolo Bitcoin impõe um tamanho máximo aos blocos e, consequentemente, às transações. Além disso, o tamanho de uma transação, como especificado em WIKI (2015e), influencia diretamente o valor mínimo da gorjeta que deve ser dada aos mineradores10 . Por outro lado, esse é um problema que pode ser amenizado em versões futuras do Bitcoin, com o ajuste dos parâmetros que regulam o tamanho dos blocos e a gorjeta mínima.
Outra maneira de contornar esse problema seria considerar versões um pouco mais complexas das transações envolvidas em Πcmm. Poderíamos considerar uma versão de Txncomp
tal que todas as saídas pertencentes ao mesmo conjunto Si fossem transformadas em uma só.
Para reivindicar tal saída seria necessário apresentar a assinatura dos m participantes. Por isso seria necessário a cooperação de todos os participantes para construir cada Txnresgi . Além disso, para cada i, Txnpeni→ j seria transformada em uma única transação com m− 1 saídas. Ou seja, basicamente transferiríamos o conjunto Si de Txncomp para a nova Txnpeni . A publicação de
10Uma transação que não dê a quantidade mínima de gorjeta tem menor prioridade para os mineradores. Por isso
Txnpeni penalizaria imediatamente Pi, mas os demais participantes precisariam de mais uma
transação para reivindicar a saída adequada de Txnpeni . Apesar de envolver mais transações e necessitar de mais cooperação entre os participantes, cada transação teria, no máximo, um tamanho proporcional a m. Consideramos a descrição e análise mais detalhadas dessa extensão de Πcmm como um possível desenvolvimento deste trabalho.
170 9 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
9.1 Considerações Finais
Ao longo dos Capítulos 6, 7 e 8 tratamos da reconstrução justa e de duas estratégias para conduzí-la que podem ser implementadas tendo o Bitcoin como plataforma. Justamente o emprego do Bitcoin por essas estratégias merece algumas considerações adicionais às que já foram feitas.
A primeira dessas considerações diz respeito à representação dos circuitos ϕique apa-
recem tanto na construção escada quanto no protocolo Πcmmrec . Esses circuitos precisam ser representados como scripts para serem utilizados pelas transações Bitcoin e, portanto, têm sua complexidade limitada pela expressividade da linguagem de script do Bitcoin. De fato, essa linguagem não é Turing-completa e, além disso, alguns de seus comandos originais foram remo- vidos por questões de segurança, como descrito em WIKI (2015g). Portanto, a complexidade de ϕié limitada pela expressividade dos scripts Bitcoin.
O segundo ponto que precisamos discutir diz respeito ao problema da maleabilidade das transações do Bitcoin. Lembramos que esse problema foi discutido na Seção 2.2. Vamos considerar seus efeitos na nossa proposta, mais especificamente sobre as transações Txncomp e Txnpeni→ j. Lembramos que Txnpeni→ j referencia Txncomp antes que ela apareça na blockchain. Depois que todas as transações Txnpeni→ j forem criadas, um participante malicioso pode, devido à maleabilidade das transações, publicar uma versão Txncomp2 equivalente a Txncomp mas com id diferente. Dessa forma, todas as transações Txnpeni→ j tornam-se inválidas.
Como mencionamos anteriormente, todas as transações que referenciam outras ainda não publicadas na blockchain estão vulneráveis a esse problema. Em particular, também a construção escada sofre desse problema, pois Txnreemi→ j referencia uma transação ainda não publicada (Txncri→ j).
Além do problema da maleabilidade, a maneira pela qual os ids das transações são gerados tem outro efeito indesejado nas construções apresentadas. Ela obriga que uma transação só possa referenciar uma outra que já esteja completa, isto é, com todas as entradas devidamente preenchidas. De fato, se um transação ainda não está completa, então seu id ainda não é o final. Como comentamos, contornamos essa característica, na nossa proposta, mantendo as transações Txndepi secretas. Outra possibilidade é admitir uma versão modificada do Bitcoin, como as discutidas na Seção 2.2. Ressaltamos que nossa proposta pode ser conduzida da mesma maneira nessas versões. De fato, ela pode até mesmo ser simplificada.
Outro ponto revelante sobre as construções apresentadas é que elas caracterizam o aborto de um participante através de sua demora em tomar parte em alguma etapa. Isso é alcançado através do campo timelock das transações. No entanto, como as comunicações na rede Bitcoin se dão sem garantias, no esquema de melhor esforço (best effort), não há como de fato ter certeza se um participante abortou ou se simplesmente sua transação ainda não apareceu na blockchain.
De maneira geral, podemos ajustar o tempo de espera de acordo com a taxa média de geração de blocos que, no Bitcoin, é de um a cada 10 minutos.
Esse tipo de estratégia pode sofrer com ataques de negação de serviço, como aponta BEEKMAN (2015). Isso porque um participante sob um desses ataques pode não conseguir enviar suas transações a tempo. Por outro lado, não apenas um participante, mas a própria rede Bitcoinpode sofrer com ataques desse tipo, como o descrito em BITSCAN (2015).
Por outro lado, como argumenta KUMARESAN; MORAN; BENTOV (2015), podemos admitir, em geral, que tais ataques são incomuns e que os participantes possuem uma conexão de boa qualidade com a Internet. Além disso, o próprio protocolo Bitcoin possui mecanismos para tornar ataques de negação de serviço caros e difíceis de serem conduzidos, como é argumentado em WIKI (2015h).