Utilizar Transacções Avançadas em Canais de Pagamento – Parte 1

No último artigo, vimos como funciona um canal de pagamento. No entanto, esse exemplo dependia da boa-fé dos intervenientes. Quando o objectivo é instalar uma rede que consiga transmitir valor, sem ter uma autoridade central a controlar, as transmissões têm que ser independentes de quaisquer valores éticos e puramente matemáticas para garantir o bom funcionamento da rede. A forma mais eficaz de conseguir resolver este problema é a aplicação de transacções avançadas que já vimos num artigo anterior.

No canal exemplo as duas partes correm riscos:

• a Maria poderia transmitir qualquer uma das transacções que tinha assinadas pelo Manuel. Deste modo, poderia prejudicar o Manuel pagando-lhe apenas o primeiro segundo do vídeo e tendo usufruído dos 10 minutos.
• ela própria corre o risco de o Manuel desaparecer. E, nesse caso, ficaria com o seu dinheiro bloqueado numa conta para a qual necessita da assinatura do Manuel para aceder. A Maria perderia as suas bitcoins para sempre.

Utilizar Trancas de Tempo

Estes dois problemas podem ser resolvidos recorrendo a uma ferramenta sobre a qual já aprendemos, e é conhecida como timelock – tranca de tempo. Esta ferramenta aplicada a uma transacção adia-a por um determinado número de blocos, logo um determinado período de tempo.

A Maria não pode arriscar enviar dinheiro para uma conta que não controla a 100% sem ter garantia de o recuperar. Para estar segura, envia ao Manuel, para que ele assine aceitando os termos que ela definiu, uma operação que emite de volta à Maria os 3600 sats que ela vai emprestar ao canal. (Representada como transacção A no esquema abaixo). Faz isto ainda antes de publicar na blockchain a transacção de fundação com esses mesmos 3600 sats. Esta restituição do dinheiro é a salvaguarda da Maria para recuperar as suas bitcoins, caso algo corra mal no canal.

Quando garantir que tem o reembolso assinado pelo Manuel, a Maria vai então transmitir a transacção de fundação para a rede Bitcoin, também esta previamente assinada pelo Manuel. A partir daqui todas as operações serão assinadas pelas duas partes, já que o canal pode ser visto como uma conta partilhada e será necessário ter assinaturas das duas partes. Com o registo na blockchain, o canal de pagamentos está criado e pronto a receber transacções.

O primeiro passo com o canal aberto, será a publicação, no canal, da primeira transacção de compromisso. É agora que a Maria vai publicar no canal a transacção que lhe devolve o dinheiro que envia para o canal. Mas, incluirá uma tranca de tempo de, por exemplo, 4000 blocos. Ou seja, esta operação ficará pendente, para ser publicada na blockchain daí a 4000 blocos, e diz que o canal deve pagar à Maria 3600 sats. Desta forma a Maria sabe que as suas bitcoins voltarão à sua posse mesmo que algo corra mal durante a duração do canal.

A partir daqui os intervenientes começarão a trocar transacções de compromisso à semelhança do exemplo do artigo anterior. A cada segundo que passar, vai ser retirado um satoshi da parte da Maria e adicionado à parte do Manuel. Quando chegar aos 600 segundos de vídeo e a Maria parar de assistir ao streaming publica a transacção de resolução que estabelece o balanço final do canal e fecha-o.

Além da salvaguarda para que a Maria recupere as suas bitcoins existe outra diferença em relação ao exemplo simples que vimos anteriormente. Todas as transacções terão também as suas trancas de tempo. No seguinte esquema: uma operação seguinte terá uma tranca de tempo com uma data anterior de modo a que seja publicada primeiro e invalide as que lhe antecedem. Ou seja, a última transacção seria a primeira a ser publicada, garantido sempre que o estado mais actual do canal é o publicado na blockchain.

De notar que, o dinheiro utilizado para todas estas operações seria sempre o mesmo e logo que uma for publicada todas as outras serão inválidas. Não poderão mais utilizar esse dinheiro. Todas as transacções com trancas de tempo ficam pendentes até que chegue o bloco no qual seriam publicadas. Só seria activada aquela que estivesse no bloco que fosse minerado mais cedo.

No entanto, se tudo correr bem as duas partes aceitam a transacção de resolução do canal em que são pagos 3000 satoshis à Maria e 600 ao Manuel – a transacção X do esquema. Esta será imediatamente publicada para a rede da Bitcoin e invalidará todas as outras que lhe seguiriam.

Apesar desta ferramenta resolver alguns problemas, o seu uso exclusivo aprensenta duas desvantagens:

1. Duração limitada do canal – ao estabelecer o tempo até quando a transacção inicial está trancada, estamos efectivamente a definir a duração máxima do canal, impedindo assim que se possa continuar a fazer transacções depois dessa data através deste canal. E, ainda, se uma das partes desaparecer o outro interveniente terá que esperar que o canal se feche para recuperar os fundos que ficaram bloqueados no canal aquando da sua fundação.
2. Limite de transacções acomodadas pelo canal –  por exemplo: um canal de 30 dias, que tenha uma tranca de tempo de 4320 blocos pode apenas acomodar 4320 transacções, já que cada operação deverá ter uma tranca de tempo um bloco antes da anterior. Só assim se consegue assegurar que será publicada primeiro.

Para ver como podemos resolver estas limitações teremos que aprender como podemos aplicar outras ferramentas aos canais de pagamento. Da conjugação de vários tipos de transacções avançadas podem produzir-se canais robustos e capazes de tornar a Bitcoin ainda mais útil e alcançar ainda mais pessoas.