Protocolo Bitcoin: tudo sobre Lightning Network

dominik-qn-45994-unsplash

No meu ultimo artigo escrevi sobre a escalabilidade do protocolo Bitcoin e vimos que, em Agosto de 2017, esta questão resultou na separação da comunidade e no nascimento do protocolo Bitcoin Cash.

A comunidade que deu origem ao protocolo Bitcoin Cash defendia um aumento do tamanho dos blocos de 1 Megabyte para 2 Megabytes, como solução imediata para os problemas de escalabilidade que se verificavam: o elevado tempo de confirmação das transações e consequente aumento dos fees.

Contudo, a comunidade que se manteve fiel ao protocolo Bitcoin original, argumentava que esta solução, além de ser de curto prazo, poderia conduzir à centralização do protocolo e, pior ainda, geraria um Hard Fork que poderia resultar na divisão da comunidade – como acabou por se verificar.

(Qualquer duvida que possam ter neste momento sobre o que acabaram de ler, será rapidamente esclarecida com a leitura do artigo acima partilhado).

Mas como vislumbrava então, o resto da comunidade Bitcoin fiel ao protocolo original, a solução para os elevados fees e tempo de confirmação das transações?

A resposta passava por soluções de layer 2. Isto é, soluções que atuassem numa segunda camada do protocolo e não no seu epicentro, evitando um Hard Fork.

Lightening Network.

Provavelmente já ouviram falar. Mais uma buzz-expression que virou moda nos últimos tempos. Mas afinal o que é?

Traduzindo para português, Lightning Network significa literalmente Rede Relâmpago. Que nos remete imediatamente para rapidez ou velocidade da luz. O que, tendo em conta o problema que se propõe resolver, faz de fato sentido.

Mas antes de percebermos o que é e como funciona, precisamos primeiro desmistificar dois conceitos.

O primeiro, é o conceito de SegWit. O termo SegWit que também surgiu recentemente, é diminutivo de Segregated Witness – que em português significa Testemunha Segregada.

É um upgrade ao protocolo Bitcoin e é essencial, ou pelo menos facilita (muito), a implementação da solução Lightning Network*.

Importa referir que, sendo um upgrade, ele é um Soft Fork e não um Hard Fork. Isto é, trata-se de um upgrade que não requer que todos os nodes o adoptem e que permite que, tanto os que o adoptam como os que não o fazem, se consigam continuar a comunicar na rede.

(Para saberem mais sobre Soft Forks e Hard Forks sugiro a leitura do meu artigo sobre o tema).

Imaginemos agora que o bloco abaixo é uma transação do protocolo Bitcoin.

Screen Shot 2018-03-02 at 12.01.41

Como podemos observar, a assinatura de uma transação (parte azul) representa mais do que 50% do seu espaço, ou dos dados da transação.

SegWit remove a assinatura de uma transação e coloca-a numa data structure (estrutura da dados) separada, chamada de Testemunha.

Agora, o protocolo Bitcoin passa a manter o registo de ambas as estruturas separadamente: a transação especificamente e a sua testemunha.

No entanto, a transação é agora muito mais pequena. Olhando para a imagem acima, será apenas a parte amarela.

Se alguém quiser validar uma transação, essa pessoa poderá olhar para a respectiva testemunha e verificar quem a assinou. Desta forma, continua a garantir-se a veracidade e segurança da informação e passa a ser possível incluir um maior número de transações em cada bloco – devido à sua agora menor dimensão.

(Para perceberem mais facilmente a funcionalidade SegWit e o resto deste artigo, é preciso compreender e dominar o conceito de transações e assinaturas. Recomendo por isso a leitura do meu artigo sobre hash functions, private keys e public keys).

O segundo conceito que precisamos desmistificar, antes de entrar a fundo na solução Lightening Network, é o conceito de Transaction Malleability – Maleabilidade das Transações, em português.

Transaction Malleability é um pequeno “erro” no source code do protocolo Bitcoin que permite alterar o ID (identidade) de uma transação sem alterar necessariamente o seu significado, ou seja, sem alterar o significado dos seus inputs e outputs.

Como obtemos o ID de uma transação? E como é possível alterar o ID de uma transação sem alterar o seu significado?

Bom, lembremo-nos do conceito de hash function. Vejamos o exemplo de uma hash function abaixo.

” SHA256 ( Screen Shot 2018-03-02 at 12.01.41 ) = Hash da transação ”

Se colocarmos uma transação bitcoin (o bloco azul e amarelo) como input, iremos obter um hash único da transação, ou se quisermos, o ID da transação.

A questão aqui é, como vimos, que transações têm assinaturas dentro delas – se não usarmos SegWit. E o pequeno erro que falámos (Transaction Malleability) permite a alteração do formato da assinatura, sem necessariamente mudar o seu significado.

Atenção aqui aos termos formato e significado. É importante saber distinguir.

No sistema binário que rege os computadores, é possível que um dos nodes altere o formato de uma assinatura de uma transação bitcoin, sem alterar o significado dessa mesma transação – por exemplo o seu valor ou os destinatário, etc.

Tal pode acontecer quando as transações são, por exemplo, propagadas pela rede e a transação “chega” a um node maldoso (malicious), que altera o formato da assinatura propositadamente, alterando assim, consequentemente também o ID da transação.

Resolver esta questão é um dos pré-requisitos para tornar a solução Lightening Network funcional, uma vez que ela se baseia em ID’s das transações.

SegWit surgiu precisamente para solucionar o problema, ao remover, como vimos, a assinatura da transação e colocando-a numa nova estrutura de dados – a testemunha.

Assim passa a ser possível a alteração do formato das assinaturas, sem que isso signifique uma alteração no hash da transação, ou do seu ID.

Podemos agora, finalmente, passar à compreensão da solução Lightning Network.

Lightning Network é uma solução de layer (camada) 2 que permite transações rápidas e de baixo custo, através de uma rede de roteamento.

Como?

“Nem todas as transações precisam acontecer na blockchain”, foi talvez o pensamento que originou a invenção desta solução.

Ao invés, queremos introduzir uma segunda layer que será capaz de efetuar transações offchain. O conceito de offchain é, para se perceber melhor, um termo com um significado semelhante a offline.

Assim, pessoas podem transacionar entre elas sem a necessidade de registar toda e cada transação na blockchain.

A solução Lightning Network introduz assim, um novo conceito muito interessante, que é o conceito de streaming money.

Imaginemos, por exemplo, que um empregador passa a pagar aos seus trabalhadores ou prestadores de serviço ao segundo. Ou que passamos a pagar ao segundo pelo streaming de música ou videos.

Estamos a falar de micro-transações, micro-pagamentos que até então não eram possíveis. E todo o espectro de possibilidades que isso abre.

Mas como funciona?

Para efeitos práticos, vou saltar a explicação de como funcionam as transações “normais” fora do âmbito Lightning Network, nomeadamente como são validadas, o que são puzzles criptográficos, miners, mempools, etc.

Já escrevi bastante sobre esses temas e podem encontrar uma listagem desses artigos aqui. Os títulos dos artigos são elucidativos e por isso será fácil encontrarem o que procuram.

Vou então assumir que esse conhecimento está já assimilado, caso contrário este artigo tornar-se-ía demasiado extenso.

A ideia por trás de Lightning Network é a criação de um canal de pagamentos offchain entre duas pessoas, com um número ilimitado de transações instantâneas e sem custos*.

Estas transações não são registadas na blockchain. Não todas. Vejamos a imagem abaixo.

Screen Shot 2018-03-02 at 16.32.17

O rectângulo verde representa a blockchain do protocolo Bitcoin e os bonecos amarelo e azul querem abrir um canal de pagamento entre eles, para poderem transaccionar instantaneamente e sem custos.

No entanto, para abrirem este canal de pagamento precisam “comprometer” um determinado montante. Neste exemplo, cada um “compromete” 0.5 BTC.

Para tal acontecer, é necessário que cada um faça uma transação normal – fora do canal de pagamento – no valor de 0.5 BTC. Estas transações serão registadas normalmente na blockchain do protocolo Bitcoin. Estão sujeitas à validação dos miners e respetivos tempos de confirmação e fees.

Mas, uma vez feitas e confirmadas as transações, é aberto o canal de pagamento entre ambos. Este canal é agora financiado por um total de 1 BTC (0.5 BTC + 0.5 BTC).

É pré-requisito da abertura de um canal de pagamento o seu próprio financiamento.

A qualquer momento este canal pode ser encerrado. Uma vez que os participantes decidam encerrar o canal, é feito o balanço e apenas o saldo final é registado na blockchain, através de uma transação normal – que terá que ser validada por um miner e um novo bloco será adicionado.

Imaginemos que dezenas de pagamentos foram feitos pelo boneco amarelo ao boneco azul, totalizando 0.3 BTC. A nova situação será então a seguinte:

Screen Shot 2018-03-02 at 17.05.55

Na prática, apenas esta nova informação – os novos saldos – precisará ser incluída na blockchain, ou se quisermos na layer (camada) 1 do protocolo.

Todas as transações que lhe deram origem enquanto o canal de pagamento esteve aberto, serão irrelevantes, deixarão de entupir a rede e acontecerão de forma instantânea e sem custos.

Até aqui, vimos apenas o exemplo entre duas pessoas. Mas não nos esqueçamos de uma característica importante da solução Lightning Network. Ela é uma rede de roteamento. Vamos então expandir o exemplo a mais participantes.

Screen Shot 2018-03-02 at 17.16.11

Neste caso temos cinco participantes e quatro canais de pagamento. Cada canal com o seu montante de financiamento.

Desta forma, o boneco vermelho e o boneco amarelo da esquerda podem transacionar valores até 2 BTC. Esse mesmo boneco amarelo pode transaccionar valores até 1 BTC com o boneco azul escuro.

O sistema de roteamento permite que o boneco vermelho transaccione diretamente com o boneco azul escuro sem necessidade de abrir um canal de pagamento direto entre ambos.

No entanto, as transações entre ambos estão limitadas ao valor mais baixo do canal intermédio que os une. Assim, apenas poderão transaccionar montantes até 1 BTC. Para transaccionarem montantes superiores, teriam que abrir um canal de pagamento direto.

Esta situação pode parecer irrelevante. No entanto, ela é mais pertinente do que aparenta. Vejamos a nova imagem abaixo.

Screen Shot 2018-03-02 at 17.25.38

Algumas pessoas receiam que a questão do financiamento dos canais de pagamento conduzirá à centralização do protocolo.

Isto é, como os canais precisam ser financiados, os intervenientes podem preferir não abrir um canal direto com quem desejam transaccionar e, ao invés, fazê-lo através de um intermediário.

Provavelmente, esse intermediário será um “grande hub“. Alguém com muitos canais abertos com muitos intervenientes e com financiamentos elevados. Por exemplo, um Banco.

Mas será que isso pode acontecer? Será que a Lightning Network levará à centralização do protocolo?

É uma incógnita. Há quem diga que sim e quem diga que não.

Contudo, não nos esqueçamos que Lightning Network é uma solução layer (camada) 2, desenvolvida em cima da layer 1 do protocolo Bitcoin. Por isso, se não resultar, pode simplesmente ser removida ou alterada.

 

=====

*1: A razão pela qual a solução Lightning Network é mais fácil de implementar agora que a questão da Transaction Malleability foi resolvida pelo SegWit é porque muitos dos seus mecanismos dependem do rastreamento de transações específicas para garantir a veracidade da informação e evitar que terceiros se apoderem de fundos indevidamente. Para que tudo funcione, é necessário que a rede rastreie ID’s de transações e por isso é imperativo que esses ID’s não se alterem.

*2: Os fees da solução Lightning Network regem-se pela regra do mercado livre. Assim cada node tem a liberdade de decidir o seu próprio fee. Por isso se diz que, tecnicamente, se pode efetuar uma transação sem custos. Mas na prática existirão provavelmente alguns custos. Contudo a ideia é que esses custos, por acontecerem numa layer (camada) 2 serão muito mais baixos, uma vez que não existirão custos com eletricidade para validação das transações como acontece na layer 1.

3 opiniões sobre “Protocolo Bitcoin: tudo sobre Lightning Network

  1. Parabéns pela organização e clareza das explicações.

    Liked by 1 person

  2. Parabéns excelente texto, só uma ressalva:
    Em seu exemplo onde as duas partes financiam o canal esse modelo não está implementado nas principais implementações. Onde apenas uma parte financia o canal, até abertura sem gastos dos seus fundos este canal ´unidirecional ele só consegue realizar pagamentos, para que ele consiga receber por este canal deve já ter gastos todos os fundos ou boa parte.

    Esse modelo de roteamento existem porém o mesmo precisa de liquidez, nesse ponto o primeiro cenário que vejo são canais sendo usados como cartões pré-pagos onde você tem um crédito com esse lojista, outro cenário seria “HUB_NODE” intermediários que forneceriam uma infraestrutura para lojistas e seus clientes bastava possui um canal com “HUB_NODE”, mais é claro tudo dependeria de um nível de confiança entre as partes. Enfim a diversas possibilidades.

    Liked by 1 person

    1. Obrigado pela ressalva Tayrone. Consegues partilhar um link com essa informação sobre os canais por favor? Quanto aos Hub Nodes, eu falei neles no final do artigo: “(…) como os canais precisam ser financiados, os intervenientes podem preferir não abrir um canal direto com quem desejam transaccionar e, ao invés, fazê-lo através de um intermediário. Provavelmente, esse intermediário será um “grande hub“.”

      Gostar

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close