Análise da Construção Escada e sua Implementação Bitcoin

E3. (Fase de Reembolso.) O objetivo desta etapa é fazer com que Pi tenha seu depósito

reembolsado através da transação Txnreem_{i→ j}.

Para isso, na rodada τ (quando a blockchain contiver T0+ τ· ∆T blocos) e se Txncr_{i→ j}

não tiver sido reivindicada, Piadiciona sua assinatura (Assina([Txnreem_{i→ j}], Ski)) ao script da

entrada de Txnreem_{i→ j} e publica essa transação na rede Bitcoin.

A Definição 7.106 não traz grandes novidades em relação ao que já discutimos sobre as transações nas seções anteriores. Ela serve principalmente para registrar o momento em que essas transações são criadas e reforçar o papel que cada uma delas tem no protocolo de maneira geral.

Na etapa de crédito (E1), ambas Txncr_{i→ j} e Txnreem_{i→ j} devem ser criadas. A transação Txncr_{i→ j} só deve ser publicada, no entanto, se Piobtiver uma assinatura válida da versão simplificada de

Txnreem_{i→ j} ([Txnreem_{i→ j} ]) feita por Pj. Como já mencionamos, é isso que garante a Pia possibilidade

de ser reembolsado caso Pjpule a etapa E2. Um ponto importante a ser notado é que, após ser

assinada por Pj, a transação Txnreem_{i→ j} torna-se “imutável”. Isto é, Pinão pode alterar nenhum dos

campos de Txnreem_{i→ j}, em particular o locktime, sem invalidá-la12.

Outro ponto importante a ser observado é que, na Definição 7.100, definimos ϕ como um circuito, enquanto que na Definição 7.106 o tratamos como um script Bitcoin. De fato, essa conversão de circuito para script precisa ser feita para que fcr admita uma implementação

baseada no protocolo Bitcoin. Por essa razão, como discutiremos mais adiante, a expressividade da linguagem disponibilizada para programar esses scripts, bem como a flexibilidade da estrutura das transações Bitcoin, são fatores críticos para que essas implementações sejam aplicáveis na prática.

Por fim, ressaltamos que é recomendado que em cada execução do protocolo da Defi- nição 7.106 sejam utilizados pares novos de chaves públicas e secretas ((Pki, Ski) e (Pkj, Skj)).

Isso serve para impedir que informações de execuções passadas sejam reutilizadas. Isso é especialmente importante porque todas as informações trocadas entre Pie Pj são, a princípio,

públicas.

7.6 Análise da Construção Escada e sua ImplementaçãoBitcoin

Como vimos, a construção escada permite uma implementação Bitcoin bastante simples. Ela é realizada, basicamente, a partir de três transações Bitcoin (Txncr_{i→ j}, Txnreem_{i→ j} e Txncred_{i→ j}). Ela atinge a noção de justiça monetária da Definição 5.95 e vai um pouco além, compensando alguns participantes honestos mesmo que a justiça (tradicional) não tenha sido quebrada.

Como aspecto negativo dessa construção, ressaltamos a assimetria dos investimentos dos participantes. De fato, o participante Piprecisa pagar até q+ (i− 1) · q moedas, com i 6= m,

para fazer seus depósitos escada e cobertura. Mesmo que no final do protocolo os participantes

12_{Isso porque a assinatura contribui para a imutabilidade da transação. No entanto, alguns campos não são}

recebam o mesmo valor de compensação, essa assimetria faz uma distinção arbitrária entre eles logo no início da execução.

Outro ponto a ser ressaltado é a falta de escalabilidade da construção escada. Para uma execução com m participantes, o protocolo dura 2_{· m rodadas}13. Cada uma dessas rodadas é caracterizada pela publicação de uma ou mais transações. De fato, uma transação só pode ser publicada em uma rodada específica e pode depender que outras transações já tenham sido publicadas. Por essa razão, as 2_{· m rodadas totais do protocolo só podem ser executadas} sequencialmente. O tempo que isso leva depende dos parâmetros ∆T e Tseg mas, se levarmos

consideração que ∆T _{≥ T}seg e que o valor recomendado pela comunidade Bitcoin para Tseg é

de seis blocos, podemos concluir que cada rodada deve durar pelo menos 60 minutos14. Nesse cenário, uma execução envolvendo apenas dois participantes (m= 2) duraria pelo menos 4 horas.

13_{No caso em que o protocolo é executado honestamente até o fim: 1 (criação dos depósitos-cobertura) +}

(m_{− 1) (criação dos depósitos-escada) + (m − 1) (reivindicação dos depósitos-escada) + 1 (reivindicação dos} depósitos-cobertura) = 2_{· m.}

14_{No caso em que ∆T = T}

sege Tseg= 6. Como um bloco é gerado, em média a cada 10 minutos, ∆T dura 60

146 8 RECONSTRUÇÃO JUSTA ATRAVÉS DE COMPROMETIMENTO MONE-

TÁRIO MULTILATERAL

8.1 Visão Geral

Como vimos no capítulo anterior, a construção escada se baseia em chamadas à fcr. Essa

funcionalidade, por sua vez, é usada para que os participantes se comprometam em revelar seus elementos da lista Pedaços. No entanto, a organização sequencial das chamadas à fcr resulta

em um protocolo com número linear (em m) de rodadas, provocando problemas como a falta de escalabilidade.

Nesta seção apresentamos uma alternativa à construção escada baseada na funcionalidade f_cmmpara comprometimento monetário multilateral. Uma única instância dessa funcionalidade permite a todos os participantes se comprometerem simultaneamente a revelar seus pedaços. Em contraste, a construção escada, por exemplo, necessita de várias instâncias de fcr organizadas em

sequência para atingir o mesmo efeito.

A funcionalidade fcmm tem 3 etapas principais: a dos depósitos-garantia, a da revelação

dos pedaços e a do resgate de depósitos e penalização. Na primeira delas, todos os participantes fazem investimentos monetários, através dos chamados depósitos-garantia e, com isso, se comprometem a agir honestamente durante o restante da execução. Agir honestamente significa, na etapa de revelação, publicar os elementos da lista Pedaços. Somente assim é possível recuperar os investimentos monetários iniciais através do resgate dos depósitos-garantia, feito na etapa seguinte. Na etapa de penalização, os participantes desonestos, os que não revelaram seus pedaços, perdem a chance de reaver seus investimentos iniciais. Esses investimentos são divididos entre os demais como forma de compensação.

A partir de fcmm, é possível definir uma funcionalidade freccmm para reconstrução justa que

admita um protocolo Πcmm_rec com número constante de rodadas. A ideia geral desse protocolo é que cada participante utilize fcmm para investir(m− 1) · q moedas e se comprometer a revelar

seu pedaço. Essa revelação deve acontecer em uma rodada predefinida τ e é a única maneira pela qual um participante recupera seu investimento. Se ele agir desonestamente, cada um dos (m_{− 1) demais participantes recebe q moedas.}

Ressaltamos que nossa proposta é semelhante à funcionalidade F_ML? de KUMARESAN e BENTOV (2014), mas foi desenvolvida de maneira independente. De fato, o trabalho de KUMARESAN e BENTOV (2014) difere do nosso porque, entre outras coisas, admite uma versão modificada do Bitcoin1, a qual contribui para facilitar a implementação de F_ML? . Nossa proposta não depende dessa modificação.

A apresentação da nossa proposta será dividida da seguinte forma. Primeiramente definiremos a funcionalidade f_reccmm para reconstrução justa. Dessa forma deixaremos claro como o problema da reconstrução justa será tratado no restante do capítulo. Em seguida exibiremos

o protocolo Πcmm_rec para computar f_reccmm no modelo fcmm-híbrido. Apresentaremos também uma

implementação de Πcmm_rec utilizando transações Bitcoin. Por fim, faremos uma análise da correção e justiça da nossa proposta, bem como de outros pontos relevantes.