Guia para Iniciantes Sobre a Lightning Network do Bitcoin
P√°gina Inicial
Artigos
Guia para Iniciantes Sobre a Lightning Network do Bitcoin

Guia para Iniciantes Sobre a Lightning Network do Bitcoin

Iniciante
Publicado em Nov 28, 2018Atualizado em Feb 14, 2023
20m

Introdução

As criptomoedas t√™m algumas propriedades bastante √ļnicas. Elas dificilmente ser√£o hackeadas ou ter√£o seu sistema desligado e qualquer um pode us√°-las para transferir valores globalmente, sem a interven√ß√£o de terceiros.

Para manter esses recursos em funcionamento s√£o necess√°rias algumas limita√ß√Ķes. Como muitos nodes (n√≥s) s√£o respons√°veis pela execu√ß√£o de uma rede de criptomoedas, a taxa de transfer√™ncia √© limitada. Sendo assim, o n√ļmero de transa√ß√Ķes por segundo (TPS) que uma rede blockchain pode processar √© relativamente baixo para uma tecnologia que pretende ser adotada globalmente.

Para superar as limita√ß√Ķes inerentes √† tecnologia blockchain, v√°rias solu√ß√Ķes de escalabilidade foram propostas visando aumentar o n√ļmero de transa√ß√Ķes que uma rede √© capaz de processar. Neste artigo, falaremos sobre a Lightning Network, uma das extens√Ķes do protocolo Bitcoin.


O que é Lightning Network?

A Lightning Network √© uma rede que opera no topo da blockchain e facilita transa√ß√Ķes¬†peer-to-peer. N√£o √© uma rede exclusiva do Bitcoin ‚Äď outras criptomoedas, como o Litecoin, a integraram.
Voc√™ pode estar se perguntando o que queremos dizer com ‚Äútopo de uma blockchain‚ÄĚ. A Lightning Network √© o que chamamos de solu√ß√£o¬†off-chain ou¬†layer-2. Ela permite que os usu√°rios realizem transa√ß√Ķes sem a necessidade de registrar todas elas na blockchain.
A Lightning Network √© separada da rede do Bitcoin ‚Äď ela tem seus pr√≥prios¬†nodes e software, mas ainda se comunica com a blockchain principal. Para entrar ou sair da Lightning Network, voc√™ precisa criar transa√ß√Ķes especiais na blockchain.

Quando voc√™ faz a sua primeira transa√ß√£o, voc√™ est√° efetivamente criando um tipo de contrato inteligente com outro usu√°rio. Veremos mais detalhes em breve ‚Äď por enquanto, basta entender que o contrato inteligente mant√©m um ledger privado com o outro usu√°rio (sua contraparte). Nesse ledger, voc√™ pode registrar muitas transa√ß√Ķes. Elas s√£o vis√≠veis apenas para voc√™ e sua contraparte, mas nenhum de voc√™s pode trapacear devido a alguns recursos peculiares da configura√ß√£o.

Este mini-ledger é conhecido como channel (canal). Suponha que Alice e Bob colocaram 5 BTC cada no contrato inteligente. Em seu canal, ambos agora teriam um saldo de 5 BTC. Alice pode registrar no ledger pagar 1 BTC a Bob. Agora, Bob tem 6 BTC e Alice tem 4. Posteriormente, Bob poderia enviar 2 BTC de volta para Alice, atualizando os saldos para 6 BTC do lado de Alice e 4 BTC do lado de Bob. Eles podem continuar fazendo isso por algum tempo.

A qualquer momento, qualquer um deles pode publicar o estado atual do canal na blockchain. Nesse momento, os saldos de cada um s√£o alocados para suas respectivas partes na blockchain.

Como o nome sugere, as transa√ß√Ķes Lightning s√£o extremamente r√°pidas. N√£o √© preciso aguardar por confirma√ß√Ķes de¬†bloco ‚Äď os pagamentos podem ser feitos muito rapidamente, dependendo da sua conex√£o de internet.


Por que a Lightning Network é necessária?

At√© o momento, a Lightning Network (LN) parece ser a abordagem mais sensata para a escalabilidade da blockchain do Bitcoin. √Č complicado coordenar mudan√ßas em um ecossistema t√£o amplo ‚Äď ¬†existe o risco de¬†hard forks e bugs potencialmente catastr√≥ficos. Com tanto valor em jogo, a experimenta√ß√£o √© incrivelmente perigosa.

Ao afastar esse tipo de experimenta√ß√£o da blockchain, h√° muito mais flexibilidade. Se algo der errado, a rede Bitcoin real n√£o sofrer√° os impactos. As solu√ß√Ķes de layer-2 n√£o prejudicam nenhuma das medidas de seguran√ßa que mant√™m o protocolo funcionando h√° mais de 10 anos.

Tamb√©m n√£o h√° obriga√ß√£o de mudar a forma tradicional de opera√ß√£o. As transa√ß√Ķes on-chain (na blockchain) continuam funcionando normalmente para o usu√°rio final, mas agora eles tamb√©m t√™m a op√ß√£o de realizar transa√ß√Ķes off-chain.

O uso da Lightning Network oferece muitos benefícios. Vamos ver alguns dos principais. 


Escalabilidade

Os blocos do Bitcoin s√£o criados a cada dez minutos e podem conter apenas algumas transa√ß√Ķes. O espa√ßo em cada bloco √© escasso, portanto, voc√™ deve fazer lances contra outros usu√°rios para que a sua transa√ß√£o seja inclu√≠da em tempo h√°bil. A principal preocupa√ß√£o dos mineradores √© receber o pagamento, ent√£o eles incluem as transa√ß√Ķes com taxas mais altas primeiro.

Quando n√£o h√° muitos usu√°rios tentando enviar fundos ao mesmo tempo, isso n√£o √© necessariamente um problema. Voc√™ pode definir uma taxa baixa e √© prov√°vel que sua transa√ß√£o seja inclu√≠da no pr√≥ximo bloco. No entanto, quando todos est√£o transmitindo transa√ß√Ķes ao mesmo tempo, a taxa m√©dia pode aumentar significativamente. Em algumas ocasi√Ķes, esse valor ultrapassou US$ 5. No auge do mercado em alta de 2017, ultrapassou US$ 50.


Taxa Média de Transação do Bitcoin (em USD)


Isso pode parecer insignificante para transa√ß√Ķes que movimentam milhares de d√≥lares em Bitcoin, mas para pagamentos menores, √© insustent√°vel. Quem vai querer pagar por um caf√© de US$ 3 com uma taxa adicional de US$ 5?

Com a Lightning Network, voc√™ ainda deve pagar duas taxas ‚Ästuma para abrir seu canal e outra para fech√°-lo. Mas ap√≥s a abertura do canal, voc√™ e sua contraparte podem fazer milhares de transa√ß√Ķes gratuitamente. Quando terminar, basta publicar o estado final na blockchain.

De maneira geral, se mais usu√°rios contarem com solu√ß√Ķes off-chain como a Lightning Network, o espa√ßo de cada bloco ser√° usado com mais efici√™ncia. Transfer√™ncias de baixo valor e alta frequ√™ncia podem ser realizadas atrav√©s de canais de pagamento, enquanto o espa√ßo de bloco √© usado para transa√ß√Ķes maiores e para abertura/fechamento de canais. Com isso, o sistema se tornaria mais acess√≠vel a uma base de usu√°rios muito mais ampla, permitindo a escalabilidade do sistema a longo prazo.


Micropagamentos

H√° uma quantidade m√≠nima de Bitcoin que voc√™ pode enviar em uma transa√ß√£o ‚Äď aproximadamente 0,00000546 BTC. Atualmente, isso equivale a cerca de vinte centavos de d√≥lar. √Č uma quantia pequena, mas a Lightning Network permite que voc√™ ultrapasse os limites para transacionar a menor unidade dispon√≠vel atualmente ‚Äď 0,00000001 BTC ou um¬†satoshi.

A Lightning √© muito mais interessante para micropagamentos. As taxas das transa√ß√Ķes regulares inviabilizam o envio de pequenas quantias na blockchain principal. Dentro de um canal, no entanto, voc√™ pode enviar uma pequena fra√ß√£o de Bitcoin gratuitamente.

Os micropagamentos são adequados para muitos casos de uso. Alguns especulam que eles poderiam ser um substituto viável para os modelos baseados em assinatura, onde os usuários pagam pequenas quantias cada vez que usam determinado serviço.


Privacidade

Outro benef√≠cio da Lightning Network √© que ela oferece aos usu√°rios um alto grau de confidencialidade. As partes n√£o precisam divulgar seus canais na rede. √Č poss√≠vel consultar a blockchain e afirmar¬†esta transa√ß√£o abriu um canal (channel), mas voc√™ n√£o ser√° necessariamente capaz de dizer o que est√° acontecendo dentro dele. Se os usu√°rios optarem por um canal privado, somente eles ter√£o acesso √†s transa√ß√Ķes realizadas.

Se Alice tiver um canal com Bob e Bob tiver um canal com Carol, Alice e Carol poderão enviar pagamentos uma para a outra através de Bob. Se Dan estiver conectado a Carol, Alice poderá enviar pagamentos a ele. Podemos imaginar isso se expandindo para uma ampla rede de canais de pagamento interconectados. Em tal configuração, após o fechamento do canal, não é possível ter certeza para quem Alice enviou fundos.


Como funciona a Lightning Network?

Explicamos como a Lightning Network depende dos canais (channels) entre os nodes. Vamos conferir mais detalhes.


Endere√ßos com m√ļltiplas assinaturas (multisignature)

Um endere√ßo¬†multisignature (ou multisig) permite o uso de m√ļltiplas¬†chaves privadas para transa√ß√Ķes/gastos. Ao criar um, voc√™ especifica quantas chaves privadas podem gastar os fundos e quantas dessas chaves s√£o necess√°rias para assinar uma transa√ß√£o. Por exemplo, um esquema 1-de-5 significa que cinco chaves podem produzir uma¬†assinatura e que apenas uma √© necess√°ria. Um esquema 2-de-3 indica que, das tr√™s chaves poss√≠veis, duas s√£o necess√°rias para gastar os fundos.

Para inicializar um canal Lightning, os participantes bloqueiam os fundos em um esquema 2-de-2. Existem apenas duas chaves privadas capazes de assinar e ambas são necessárias para a movimentação de moedas. Vamos usar nossos amigos Alice e Bob como exemplo novamente. Eles farão muitos pagamentos um ao outro nos próximos meses, então decidem abrir um canal da Lightning Network.

Primeiro, os dois depositam, digamos, 3 BTC cada no endereço multisig de propriedade conjunta. Vale reiterar que Bob não pode transferir fundos do endereço sem que Alice concorde, e vice-versa. 

Agora, eles podem apenas manter anota√ß√Ķes e ajustar os saldos de cada lado. Ambos t√™m um saldo inicial de 3 BTC. Se Alice quiser fazer um pagamento de 1 BTC para Bob, por que n√£o simplesmente anotar que Alice agora possui 2 BTC e Bob possui 4 BTC? Os saldos podem ser rastreados dessa maneira at√© que eles decidam transferir os fundos para outro endere√ßo.

Isso é possível, mas não é o cenário ideal. E o mais importante, com esse método é incrivelmente fácil que algum deles não coopere, certo? Se, no fim das contas, Alice tiver 6 BTC e Bob nenhum, Bob não perderá nada caso se recuse a liberar os fundos (exceto, talvez, sua amizade com Alice).


Hash Timelock Contracts (HTLC)

O sistema mencionado acima n√£o tem muito a oferecer, considerando as op√ß√Ķes de configura√ß√Ķes confi√°veis de hoje. Fica muito mais interessante quando introduzimos um mecanismo que imp√Ķe o ‚Äúcontrato‚ÄĚ entre Alice e Bob. Se uma das partes n√£o seguir as regras, a outra ainda ter√° uma maneira de retirar seus fundos do canal.

Esse mecanismo é o Hash Timelock Contract (ou HTLC). O termo pode assustar, mas na verdade é um conceito bastante simples de entender. Ele une duas outras tecnologias (hashlocks e timelocks) para remediar qualquer comportamento não cooperativo em canais de pagamento.
Um hashlock √© uma condi√ß√£o colocada em uma transa√ß√£o que determina que voc√™ s√≥ pode gastar fundos se provar que tem conhecimento sobre um segredo. O remetente faz o¬†hashing de um conjunto de dados e inclui o¬†hash na transa√ß√£o do destinat√°rio. O destinat√°rio s√≥ poder√° gastar os fundos se ele fornecer os dados originais (o segredo) correspondentes ao hash. E a √ļnica maneira de se obter esses dados √© recebendo-os do remetente.
Um timelock √© uma condi√ß√£o que impede voc√™ de gastar fundos antes de um momento espec√≠fico. √Č determinada uma hora ou uma¬†altura de bloco espec√≠fica.

Os HTLCs s√£o criados atrav√©s da combina√ß√£o de hashlocks e timelocks. Na pr√°tica, os HTLCs podem ser usados para criar pagamentos condicionais ‚Äď o destinat√°rio deve fornecer um segredo antes de um prazo determinado ou o remetente poder√° recuperar os fundos. A explica√ß√£o desta pr√≥xima parte provavelmente fica mais f√°cil com um exemplo, ent√£o vamos voltar ao exemplo de Alice e Bob.


Abrindo e fechando canais

No exemplo de Alice e Bob, eles criaram transa√ß√Ķes que financiam o endere√ßo multisignature compartilhado por eles. Mas essas transa√ß√Ķes ainda n√£o foram publicadas na blockchain! Antes disso, no entanto, precisamos fazer mais uma coisa.


Três moedas de Bob e três moedas de Alice.


Lembre-se, a √ļnica maneira de transferir essas moedas do multisig √© se Alice e Bob assinarem uma transa√ß√£o em conjunto. Se Alice quiser enviar todas as seis moedas para um endere√ßo externo, ela precisaria da aprova√ß√£o de Bob. Primeiro, ela criaria uma transa√ß√£o (seis bitcoins para este endere√ßo) e ent√£o adicionaria a pr√≥pria assinatura.¬†

Ela poderia tentar transmitir a transação imediatamente, mas seria inválida porque Bob não incluiu sua assinatura. Alice deve entregar a transação incompleta a ele primeiro. Após Bob adicionar sua assinatura, a transação se tornará válida.

Ainda não estabelecemos um mecanismo para garantir que todos atuem honestamente. Como dissemos anteriormente, se sua contraparte se recusar a cooperar, seus fundos ficarão efetivamente bloqueados. Vamos ver detalhes sobre o mecanismo que evita esse tipo de situação. São diferentes peças móveis, então vamos com calma.

Cada parte precisa inventar um segredo ‚Äď vamos chamar esses segredos de¬†"As"¬†e¬†"Bs". Seriam p√©ssimos segredos se Alice e Bob os revelassem, ent√£o eles os manter√£o ocultos por enquanto. O par ir√° gerar os respectivos hashes dos segredos ‚Ästh(As)¬†e¬†h(Bs). Ent√£o, em vez de compartilhar seus segredos, eles compartilham esses hashes um com o outro.


Alice e Bob compartilham os hashes de seus segredos um com o outro.


Alice e Bob tamb√©m devem criar um conjunto de¬†transa√ß√Ķes de compromisso antes de publicar suas primeiras transa√ß√Ķes no endere√ßo multisig. Com isso, ambos ter√£o uma garantia caso o outro decida manter os fundos bloqueados.

Se voc√™ pensar em um channel (canal) como o mini-ledger que mencionamos anteriormente, as transa√ß√Ķes de compromisso s√£o as atualiza√ß√Ķes feitas no ledger. Sempre que voc√™ cria um novo par de transa√ß√Ķes de compromisso, voc√™ est√° reequilibrando os fundos entre os dois participantes.

A transa√ß√£o de Alice ter√° duas sa√≠das (outputs) ‚Äď uma que paga um endere√ßo que ela possui e outra que est√° bloqueada em um¬†novo endere√ßo multisig. Ela assina a transa√ß√£o e passa para Bob.


Transa√ß√£o de Alice com duas sa√≠das (outputs) ‚Äď uma para seu pr√≥prio endere√ßo e outra para um novo multisig. Ela ainda precisa da assinatura de Bob para validar a transa√ß√£o.


Bob faz o mesmo ‚Äď uma sa√≠da paga a ele mesmo, a outra paga outro endere√ßo multisig. Ele assina a transa√ß√£o e passa para Alice.


Temos duas transa√ß√Ķes incompletas que s√£o muito semelhantes.


Normalmente, Alice poderia adicionar uma assinatura √† transa√ß√£o de Bob para torn√°-la v√°lida. No entanto, voc√™ notar√° que esses fundos est√£o sendo gastos no esquema multisig 2-de-2 que¬†ainda n√£o financiamos. √Č como tentar compensar um cheque de uma conta sem fundos. Portanto, essas transa√ß√Ķes parcialmente assinadas s√≥ poder√£o ser usadas quando o multisig estiver funcionando.¬†

Os novos endere√ßos multisignature (destino dos 3 outputs de BTC) possuem algumas propriedades peculiares. Vamos dar uma olhada na transa√ß√£o incompleta que Alice assinou e enviou a Bob. O output do multisig pode ser gasto nas seguintes condi√ß√Ķes:

  1. Ambas as partes podem assinar a transação cooperativamente.
  2. Bob pode gastar o valor do output por conta própria após um determinado período (devido ao timelock).
  3. Alice pode gastar o valor se souber o segredo Bs de Bob.

Em relação à transação que Bob enviou à Alice:

  1. Ambas as partes podem assinar a transação cooperativamente.
  2. Alice pode gastar o valor por conta própria após um determinado período.
  3. Bob pode gastar o valor se souber o segredo As de Alice.

Tenha em mente que nenhuma das partes conhece o segredo da outra, ent√£o o item 3) ainda n√£o √© uma possibilidade. Outra observa√ß√£o importante √© que, se voc√™ assinar uma transa√ß√£o, sua contraparte pode gastar o valor imediatamente, pois n√£o h√° condi√ß√Ķes especiais para o output (sa√≠da). Voc√™ pode esperar que o timelock expire para gastar os fundos por conta pr√≥pria ou cooperar com a outra parte para gast√°-los imediatamente.

Ok! Agora voc√™ pode publicar as transa√ß√Ķes no endere√ßo multisignature 2-de-2 original. Finalmente √© seguro faz√™-lo, j√° que voc√™ pode recuperar seus fundos caso a sua contraparte abandone o canal.

Assim que as transa√ß√Ķes forem confirmadas, o canal estar√° funcionando. Esse primeiro par de transa√ß√Ķes nos mostra o estado atual do mini-ledger. Atualmente, ele pagar√° 3 BTC para Bob e 3 BTC para Alice.¬†

Quando Alice quiser fazer um novo pagamento a Bob, eles criam duas novas transa√ß√Ķes que substituir√£o o primeiro conjunto. O processo √© o mesmo ‚Äď as transa√ß√Ķes estar√£o parcialmente assinadas. Primeiramente, no entanto, Alice e Bob descartam seus antigos segredos e usam novos hashes para a pr√≥xima rodada de transa√ß√Ķes.


¬†Se Alice quisesse pagar 1 BTC para Bob, por exemplo, as duas novas transa√ß√Ķes creditariam 2 BTC para Alice e 4 BTC para Bob. Desta forma, o saldo estaria atualizado.


Qualquer uma das partes pode assinar e transmitir uma das transa√ß√Ķes mais recentes a qualquer momento para ‚Äúresolv√™-la‚ÄĚ na blockchain. Mas a parte que fizer isso precisar√° esperar at√© que o timelock expire, enquanto a outra pode gastar imediatamente. Lembre-se, se Bob assinar e transmitir a transa√ß√£o de Alice, ela ter√° um output (sa√≠da) que n√£o envolve condi√ß√Ķes.

Ambas as partes podem concordar em fechar o canal juntas (um fechamento cooperativo). Esta é provavelmente a maneira mais fácil e rápida de recuperar os fundos na blockchain. No entanto, mesmo que uma das partes se recuse a cooperar, a outra ainda pode recuperar seus fundos aguardando o tempo do timelock.



Quer começar a investir em criptomoedas? Compre Bitcoin na Binance!



Como a Lightning Network evita trapaças?

Talvez você tenha identificado um vetor de ataque nesse processo. Se Bob atualmente tem um saldo de 1 BTC, o que o impede de transmitir uma transação mais antiga, de quando ele tinha um saldo maior? Ele já tem a transação semi-assinada de Alice, ele só precisa adicionar sua assinatura e transmiti-la, certo?
Nada o impede de fazer isso ‚Ästexceto o fato de que ele pode perder todo o seu saldo. Digamos que transmita uma transa√ß√£o antiga que paga uma moeda para Alice e cinco para aquele endere√ßo multisig que mencionamos anteriormente.

Alice recebe sua moeda imediatamente. Bob, por outro lado, deve esperar at√© que o timelock expire para gastar o valor do endere√ßo multisig. Voc√™ se lembra da outra condi√ß√£o que mencionamos, que permitiria que Alice gastasse os mesmos fundos imediatamente? Para isso, ela precisava de um segredo que ela n√£o tinha naquele momento. Mas agora ela tem essa informa√ß√£o ‚Ästassim que a segunda rodada de transa√ß√Ķes foi criada, Bob revelou seu segredo.

Enquanto Bob fica sentado, incapaz de fazer qualquer coisa enquanto espera que o timelock expire, Alice pode movimentar os fundos. Esse mecanismo de "punição" faz com que seja muito improvável que os participantes tentem trapacear, já que a contraparte terá acesso às suas moedas.


Roteamento de transa√ß√Ķes

Falamos sobre isso anteriormente ‚Äst√© poss√≠vel conectar os canais (channels). Se n√£o fosse poss√≠vel, a Lightning Network n√£o seria t√£o √ļtil para pagamentos. Voc√™ bloquearia US$ 500 em um canal com uma cafeteria apenas para obter sua dose di√°ria de caf√© pelos pr√≥ximos meses?

Voc√™ n√£o precisa fazer isso. Se Alice abrir um canal com Bob e Bob j√° tiver um com Carol, Bob pode encaminhar pagamentos atrav√©s das duas. Esse mecanismo tamb√©m funciona em m√ļltiplos "hops" (saltos), ou seja,¬†Alice pode efetivamente pagar qualquer pessoa que esteja conectada a uma dessas "rotas".


Nesse cen√°rio, Alice pode utilizar m√ļltiplas rotas para chegar at√© Frank. Na pr√°tica, ela sempre vai usar a mais f√°cil.


Os intermediários podem cobrar uma pequena taxa por seu papel de roteamento (embora não seja uma obrigação). A Lightning Network ainda é muito nova, então um mercado de taxas ainda não se concretizou. E expectativa de muitos é ver taxas baseadas na liquidez fornecida. 

Normalmente, na blockchain, sua taxa se baseia apenas no espa√ßo que sua transa√ß√£o ocupa em um bloco ‚Äď o valor da transa√ß√£o n√£o importa ‚Äď a taxa para pagamentos de US$ 1 ou US$ 10.000.000 ser√° a mesma. Por outro lado, na Lightning Network n√£o existe a quest√£o de espa√ßo no bloco.¬†

Em vez disso, h√° o conceito de¬†saldo local e saldo remoto. O saldo local √© o valor que voc√™ pode ‚Äúempurrar‚ÄĚ para a outra extremidade do canal, enquanto o saldo remoto √© aquele que sua contraparte pode enviar para voc√™.
Mais um exemplo. Vamos observar uma das rotas mencionadas acima: Alice <> Carol <> Frank.


Saldo dos usuários antes e depois de uma transferência de 0,3 BTC de Alice para Frank.


As rotas Alice <> Carol e Carol <> Frank têm uma capacidade total de 1 BTC cada. O saldo local de Alice é de 0,7 BTC. Se eles consolidarem os saldos na blockchain agora, ela receberia 0,7 BTC e Carol receberia o saldo remoto (ou seja, 0,3 BTC).

Se Alice quiser enviar 0,3 BTC para Frank, ela "empurra" 0,3 BTC para o lado de Carol do canal. Ent√£o, Carol envia 0,3 BTC de seu saldo local ao seu canal com Frank. Como resultado, o saldo de Carol permanece o mesmo: +0,3 BTC de Alice e -0,3 BTC para Frank.

Carol não tem prejuízos ao atuar como uma conexão entre Frank e Alice, mas ela perde em termos de flexibilidade. Observe, agora ela pode gastar 0,6 BTC em seu canal com Alice, mas apenas 0,1 BTC no canal com Frank.

Imagine que Alice esteja conectada apenas a Carol, enquanto Frank está conectado a uma rede muito mais ampla. Antes, Carol podia enviar um total de 0,4 BTC para outras pessoas através de Frank, mas agora ela só pode enviar 0,1 BTC, pois é o valor restante que ela tem no canal.

Nesse cen√°rio, Alice est√° efetivamente consumindo a liquidez de Carol. Sem algum tipo de incentivo, Carol pode n√£o querer essa posi√ß√£o menos favor√°vel. Portanto, ela pode simplesmente¬†cobrar uma taxa de 10 satoshis para cada 0,01 BTC transferido.¬†Dessa forma, quanto maior o valor de saldos locais que Carol sacrifica em rotas ‚Äúmais fortes‚ÄĚ, mais ela lucra.

Como mencionado anteriormente, não há uma exigência para a cobrança de taxas. Alguns usuários talvez não se preocupem com a redução da liquidez. Outros podem simplesmente abrir canais diretamente com o destinatário.


Limita√ß√Ķes da Lightning Network

Seria fant√°stico se a Lightning Network provasse ser a solu√ß√£o para todos os problemas de escalabilidade do Bitcoin. Infelizmente, ela tem suas pr√≥prias defici√™ncias e limita√ß√Ķes.¬†


Usabilidade

O Bitcoin n√£o √© o sistema mais intuitivo para iniciantes ‚Äď endere√ßos, taxas e outros aspectos podem ser confusos a princ√≠pio. No entanto, as¬†carteiras podem poupar os usu√°rios de alguns conceitos mais t√©cnicos e oferecer algo vagamente semelhante aos sistemas de pagamento tradicionais. O usu√°rio pode simplesmente fazer o download de uma carteira de smartphone, abastec√™-la com moedas, e pronto.

No momento, isso n√£o √© poss√≠vel com a Lightning Network. As op√ß√Ķes s√£o limitadas quando se trata de aplicativos de smartphone ‚Äď geralmente, os nodes da Lightning exigem acesso a um node de Bitcoin para serem totalmente utiliz√°veis.

Além disso, depois que um cliente é configurado, o usuário precisa abrir canais antes de efetuar pagamentos. Este pode ser um processo demorado e complicado para um recém-chegado, com pouco conhecimento sobre conceitos como capacidade de inbound/outbound.

Dito isso, melhorias estão sendo feitas constantemente para reduzir as barreiras de entrada e fornecer uma experiência mais simplificada aos usuários.


Liquidez

Uma das maiores cr√≠ticas √† Lightning Network √© a sua capacidade restrita de realizar transa√ß√Ķes. N√£o √© poss√≠vel gastar mais do que foi bloqueado em um canal. Se voc√™ gastar todos os seus fundos at√© que o saldo remoto represente todos os fundos do canal (channel), voc√™ precisar√° fechar o canal. Como alternativa, voc√™ pode esperar at√© que algu√©m lhe pague, mas essa n√£o √© a op√ß√£o ideal.

As rotas também podem ser limitadas pela capacidade total do canal. Pense no exemplo anterior de Alice <> Carol <> Frank. Se o canal de Alice e Carol tiver capacidade para 5 BTC, mas o de Carol e Frank tiver capacidade para apenas 1 BTC, Alice nunca poderá enviar mais de 1 BTC. Mesmo assim, todo o saldo precisaria estar do lado de Carol no canal Carol <> Frank para que a transação funcionasse. Isso pode limitar drasticamente a quantia de fundos que podem ser enviados através dos canais LN e, portanto, tem um efeito indireto na usabilidade.


Hubs centralizados

Por conta do problema mencionado na se√ß√£o anterior, existe uma preocupa√ß√£o de que a rede facilite a cria√ß√£o de ‚Äúhubs‚ÄĚ gigantes. Ou seja, hubs de grandes organiza√ß√Ķes/entidades, fortemente conectadas e com muita liquidez. Nesse cen√°rio, qualquer pagamento com valores significativos precisaria ser encaminhado atrav√©s dessas entidades.

Obviamente, essa n√£o seria uma situa√ß√£o interessante. Isso enfraqueceria o sistema, pois se algumas dessas entidades ficassem offline ou tivessem problemas, a grande maioria das conex√Ķes entre peers (pares) seria interrompida. H√° tamb√©m um risco maior de censura, j√° que existem apenas alguns pontos pelos quais as transa√ß√Ķes est√£o fluindo.


O estado atual da Lightning Network

Atualmente, em março de 2022, a Lightning Network funciona bem. A rede possui mais de 35.000 nodes online, 85.000 channels ativos e mais de 3.570 BTC de capacidade.


Distribuição global de nodes da Lightning Network. Fonte: explorer.acinq.co


Existem v√°rias implementa√ß√Ķes de nodes diferentes ‚Ästc-lightning da Blockstream,¬†Lightning Network Daemon da Lightning Labs e¬†Eclair da ACINQ s√£o alguns dos mais populares. Muitas empresas oferecem nodes plug-and-play para usu√°rios menos t√©cnicos. A √ļnica coisa que voc√™ precisa fazer √© ligar o dispositivo e pronto. Voc√™ j√° pode come√ßar a usar a Lightning Network.


Considera√ß√Ķes finais

Desde o lançamento da mainnet (rede principal) em 2018, a Lightning Network teve um crescimento impressionante, apesar de muitos considerarem que ela ainda está na versão beta.

Ainda existem alguns obstáculos em termos de usabilidade a serem superados, pois atualmente é necessário um certo grau de proficiência técnica para operar um node da Lightning. Mas com o rápido desenvolvimento que estamos presenciando, as barreiras de entrada serão cada vez menores. 

Se esses problemas forem resolvidos, a Lightning Network pode se tornar uma parte fundamental do ecossistema Bitcoin, oferecendo um enorme ganho em termos de escalabilidade e velocidade das transa√ß√Ķes.