F 2 corpo finito com dois elementos
2.2 O Problema da Maleabilidade das Transações
Uma fragilidade presente no protocolo Bitcoin é a chamada maleabilidade das transações. Ela consiste na possibilidade de se criar duas transações semânticamente equivalentes mas com idsdiferentes. O id de uma transação é o valor hash calculado sobre seus campos, incluindo, em particular, suas entradas. Isso contrasta, por exemplo, com o modo pelo qual as assinaturas adicionadas nas entradas são geradas. Como mencionamos, tais assinaturas são geradas sobre a versão simplificada da transação, a qual não possui todas as entradas.
Para entender o efeito da maleabilidade das transações, considere o seguinte cenário. Alice e Bob firmam um contrato no qual Alice se compromete a fazer um pagamento a Bob depois de 1 mês. Para garantir que esse pagamento vai acontecer, Bob pede que Alice crie a transação TA→B que transfere a quantia combinada para ele. Essa transação só pode ser
reivindicada através da apresentação de duas assinaturas: uma de Alice e outra de Bob. Bob então cria uma transação TB e pede para Alice assiná-la. Ela então confere se o campo locktime
está configurado corretamente e, se estiver, gera sua assinatura.
De fato, TBgarante a Alice que Bob não vai reivindicar TA→Bantes do prazo determinado,
pois Bob não pode alterar o locktime de TB sem invalidar a assinatura de Alice. Isso porque o
campo locktime faz parte da versão simplificada da transação. Por isso, Alice precisa apenas confiar no funcionamento do Bitcoin, e não em Bob.
2.2. O PROBLEMA DA MALEABILIDADE DAS TRANSAÇÕES 32
entrada de TA→Badicionando instruções que não lhe alterem o funcionamento10 depois de TB
ter sido criada. Ao mudar uma entrada, Alice muda também o id de TA→B. Mas note que TB
usa esse id para referenciar TA→B. Note também que Bob não pode simplesmente corrigir o id
porque isso invalidaria a assinatura de Alice em TB. A conclusão é que Bob não poderia mais
reivindicar TA→B.
Esse cenário, no entanto, pode receber uma complicação extra. Imagine que Alice não tenha a intenção de prejudicar Bob. Ela publica a transação TA→B do jeito que foi criada. No
entanto, antes de aparecer na blockchain, essa transação é publicada na rede Bitcoin, onde será recebida por mineradores, adicionada em algum bloco, o qual terá sua prova de trabalho calculada. Só então ela aparecerá na blockchain. Nesse meio tempo, a maleabilidade da transação TA→B poderia ser explorada por uma terceira parte externa, Charle, por exemplo. Ele poderia alterar uma das entradas de TA→Bcriando TA0→Be invalidando a transação TB.
Esses cenários em que a maleabilidade das transações é explorada podem parecer, à primeira vista, “artificiais”. Isso porque eles podem ser evitados se Bob, por exemplo, exigisse que a transação criada por Alice aparecesse na blockchain para só então criar TB. De fato, para
a maior parte dos usuários do Bitcoin, que utilizam as transações da maneira mais comum, a maleabilidade não deveria ser um problema. Como mostrado em ANDRYCHOWICZ et al. (2015), esses usuários só são atingidos pelo problema da maleabilidade se o software utilizado por eles para se conectar com o Bitcoin for defeituoso.
Para continuar nossa discussão, vamos considerar três aspectos que contribuem para a maleabilidade das transações:
1. O id de uma transação é calculado sobre todos os seus campos, inclusive as entradas, 2. Uma transação TBreferencia uma transação TA→Bque ainda não apareceu na block-
chain,
3. A transação TBprecisa de uma assinatura feita com uma chave secreta não acessível
a seu criador e sobre um conteúdo mutável.
Como mencionamos, os usuários mais comuns do Bitcoin não são afetados pela malea- bilidade das transações porque evitam o aspecto 2. No entanto, esse aspecto é essencial para a criação de contratos utilizando o Bitcoin. De fato, várias das transações que serão apresentadas no Capítulo 6 referenciam outras ainda não presentes na blockchain.
A seguir, apresentaremos três propostas de solução para o problema da maleabilidade. As duas primeiras atacam o aspecto 1, enquanto que a última se concentra no aspecto 3.
2.2.1 Proposta 1: ANDRYCHOWICZ et al. (2014a)
Uma solução relativamente simples para o problema da maleabilidade das transações é proposta por ANDRYCHOWICZ et al. (2014a). Como vimos, esse problema decorre do fato de
10Como uma instrução push seguida de uma pop. Ou Alice poderia simplesmente assinar a transação novamente,
que o id das transações é calculado sobre todos os campos da transação, inclusive suas entradas. Então uma solução é fazer com que o id de uma transação seja calculado sobre sua versão simplificada, da mesma maneira com que as assinaturas são calculadas. Dessa forma, toda vez que alguma modificação alterar o id de uma transação, ela também vai invalidar as assinaturas da transação.
2.2.2 Proposta 2: KUMARESAN e BENTOV (2014)
Como argumentado por KUMARESAN e BENTOV (2014), a Proposta 1 pode acarretar em uma perda de expressividade que as transações atualmente possuem. Isso porque, de acordo com essa proposta, os ids das transações deixariam, naturalmente, de refletir as informações contidas nas entradas, as quais podem ser importantes para a criação de contratos.
Para resolver o problema, KUMARESAN e BENTOV (2014) propõem adotar a Proposta 1 parcialmente. Ou seja, as transações passariam, na prática, a possuir dois ids. O calculado sobre sua versão simplificada serviria para ser referenciado por outras transações, como proposto em ANDRYCHOWICZ et al. (2014a). Já o outro identificador, calculado sobre toda a transação, como ocorre atualmente, seria utilizado para referenciar a transação na árvore de Merkle que a contém dentro de um bloco.
2.2.3 Proposta 3: ANDRYCHOWICZ et al. (2015)
A modificação da proposta 3 não afeta o Bitcoin, mas sim a maneira pela qual os contratos são escritos.
Vamos considerar o exemplo das transações TA→Be TBdado anteriormente. A proposta
de ANDRYCHOWICZ et al. (2015) é remover a necessidade de se ter a assinatura de Alice em TB. Mais especificamente, TA→B deve ser reivindicada mediante a apresentação de uma
assinatura de Bob e um valor secreto conhecido por Alice.
Inicialmente, para criar TA→B, Alice escolhe aleatoriamente um valor s e entrega para
Bob o valor hdef= H(s), em que H é uma função hash. Para reivindicar essa transação, Bob precisa colocar em TBuma assinatura sua e o valor s, que ele ainda não conhece. Como o acordo
entre eles é que TA→Bsó pode ser reivindicada após 1 mês, Alice precisa esperar esse tempo para
entregar s para Bob. Note que assim que Bob conhecer s ele poderá reivindicar TA→B11.
O problema da maleabilidade é resolvido porque TA→Bpode ser prontamente publicada
na blockchain. Nesse caso, TBnão precisa referenciar uma transação “escondida”. A preocupação
de Bob agora é outra: como garantir que Alice vai de fato revelar o valor s correto?
Para resolver isso, os autores se baseiam em uma construção apresentada por eles em ANDRYCHOWICZ et al. (2014b). De maneira geral, eles propõem a utilização de um esquema de comprometimento baseado no Bitcoin12. Ele funciona como a seguir. Alice cria uma transação
11A validade dessa ideia se baseia na propriedade de não-colisão de H, a qual garante que é difícil encontrar
s06= s tal que H(s0) = H(s). Apresentamos esse conceito na Definição 3.22.