A Lightning Network provavelmente é a inovação tecnológica mais esperada a ser implantada no Bitcoin. A camada de pagamento, proposta pela primeira vez por Joseph Poon e Tadge Dryja há cerca de um ano, prometeu suportar um número praticamente ilimitado de transações fora da blockchain entre usuários, quase sem custos – ao alavancar a segurança oferecida pelo Bitcoin.
Pelo menos três empresas – Poon and Dryja’s Lightning, Blockstream e Blockchain – atualmente estão trabalhando em implementações da tecnologia. Mas poucas além destas compreendem plenamente como o “futuro dos micro pagamentos” está configurado para impulsionar a capacidade do Bitcoin.
Este artigo será dividido em três partes e mostrará o básico da construção de blocos da Lightning Network e como eles se encaixam para realizar esta próxima camada de protocolo.
Esta primeira parte da série estabelece o necessário dos blocos e mostra como estes podem ser combinados para criar “contratos inteligentes”, que podem ser aplicados para realizar o primeiro requisito da Lightning Network: um canal de pagamento bidirecional.
Construindo o Bloco #1: Transações não confirmadas
No seu coração, o protocolo Bitcoin consiste em transações, que normalmente estão ligadas a transações anteriores e potencialmente a transações futuras. Cada transação contém entradas (inputs), que se referem a endereços de bitcoins que enviaram e saídas (outputs), que se referem aos endereços de bitcoins para qual foi enviada. Além disso, os inputs devem incluir os requisitos para enviar os bitcoins, como assinaturas que comprovem a “propriedade” dos endereços. Os resultados, entretanto, estabelecem os novos requisitos, que devem ser incluídos no input de uma transação subsequente.
Como uma das principais características, a Lightning Network é construída a partir de transações de Bitcoin mais ou menos regulares. É só que essas transações geralmente não são realmente transmitidas pela rede Bitcoin. Em vez disso, eles são armazenados localmente, nos nodes de usuários, mas podem ser transmitidos pela rede a qualquer momento.
Construindo o Bloco #2: Proteção Contra o Gasto Duplo
O segunda parte da Lightning Network provavelmente não exige muita explicação, pois é indiscutivelmente a razão de ser do próprio Bitcoin: proteção contra gasto duplo. Se duas transações (ou: entradas) dependem da mesma saída, apenas uma pode confirmar.
O importante a ter em mente aqui é que mesmo as transações não confirmadas podem ser conflitantes, o que significa que só uma pessoa pode confirmar.
Construindo o Bloco #3: Multi Assinatura
O terceiro bloco de construção da Lightning Network também é direto: endereços multi assinaturas (multisig). (Ou: endereços P2SH).
Os endereços Multisig são endereços Bitcoin que – como o nome sugere – exigem várias chaves privadas para “desbloquear” e gastar os bitcoins. Os endereços multisig podem ser configurados em todos os tipos de condições. Por exemplo, para exigir duas das três chaves possíveis, ou quinze de quinze, ou apenas sobre qualquer outra combinação.
A Lightning Network geralmente usa duas de duas (2-de-2) assinaturas múltiplas . Desbloquear bitcoins de endereços multisig 2-de-2 requer duas assinaturas, a partir de duas chaves dedicadas.
Construindo o Bloco #3: Time-Locks
O quarto bloco de construção é o Time-lock. Time-Locks podem “bloquear os bitcoins” em uma saída (output), para torná-los gastáveis (para serem incluídos em um input subseqüente) em algum momento no futuro.
Existem dois tipos diferentes de time-locks: o tipo absoluto, chamado CheckLockTimeVerify (CLTV) e o tipo relativo, CheckSequenceVerify (CSV). O CLTV bloqueia bitcoins até (mais ou menos) um tempo concreto no futuro: uma hora e uma data reais, ou um bloco específico. O CSV, em vez disso, usa o tempo relativo. Uma vez que um CVS-output é gravado no bloco, leva uma quantidade específica de blocos a partir desse ponto antes que os bitcoins possam ser gastos novamente.
Construindo o Bloco #3: Valor e Segredo do hash
O quinto e último bloco de construção – criptografia – é o bloco de construção mais fundamental do próprio Bitcoin. Mas na rede Lightning, ele é aplicada de uma maneira nova.
Em suma, um “valor” ou “segredo” é uma série longa e única de números que é praticamente impossível de adivinhar, mesmo para um computador com tentativas infinitas. Com um cálculo especial, esse valor (ou segredo) pode ser “transformado” em uma série diferente de números, um “hash”. E aqui está o truque: qualquer pessoa que conheça o valor pode facilmente reproduzir o hash. Mas isso não funciona ao contrário; É uma rua de sentido único.
Este truque pode ser utilizado no próprio Bitcoin, para “bloquear bitcoins”. (Na verdade, é assim que o Bitcoin funciona.) Por exemplo, um hash pode ser incluído em uma saída (output) e exigir a entrada (input) subseqüente para incluir o valor correspondente para ser gasto.
Primeiro desafio: Canais de pagamento Bidirecionais
Mesmo antes da apresentação da Lightning Network, o conceito de canais de pagamento já estava sendo discutido. Os canais de pagamento típicos são úteis para determinados fins, mas também são limitados: eles são unidirecional. Alice pode pagar Bob várias transações fora da blockchain, mas Bob não pode pagar Alice pelo mesmo canal.
Como uma característica chave da Lightning Network, foi proposto canais de pagamento bidirecionais sem necessidade de confiança em terceiros.
Abrindo o Canal
Para configurar um canal de pagamento bidirecional, ambas as partes envolvidas devem primeiro concordar com uma transação de abertura. Essa operação de abertura determina quantos bitcoins cada um deposita no canal.
Digamos que Alice quer enviar um bitcoin para Bob. Como Alice e Bob esperam transacionar com mais freqüência, eles decidem abrir um canal de pagamento bidirecional e usar isso para enviar o bitcoin. (Enviar um bitcoin inteiro provavelmente é muito para um canal de pagamento, pois estes podem ser mais úteis para micropagamentos – mas é perfeitamente possível.)
Para abrir o canal, Alice e Bob enviam, cada um, cinco bitcoins para um endereço 2-de-2 multisig. Esta é a “transação de abertura”. Os Bitcoins só podem ser gastos a partir deste endereço se Alice e Bob assinam uma transação subseqüente.
Além disso, Alice e Bob criam um segredo (uma série de números) e trocam o hash.
Alice agora cria imediatamente uma transação subseqüente da transação de abertura. Esta é uma “transação de compromisso”. Com a transação de compromisso, Alice envia quatro bitcoins para si mesma, e seis bitcoins para um segundo endereço multisig. Este segundo endereço pode ser desbloqueado por Bob por conta própria, mas somente após 1000 blocos extras serem extraídos depois que ele está incluído na blockchain; Foi Incluido um CSV-lock. Ou, pode ser aberto por Alice por conta própria, mas somente se ela também incluir o segredo pelo qual Bob acaba de dar-lhe o hash. (Claro, Alice não tem ideia do que é esse segredo – ela só conhece o hash – então não há como ela poder usar esta opção agora).
Alice assina o fim dessa transação de compromisso. Mas ela não o transmite! Em vez disso, ela dá ao Bob.
Enquanto isso, Bob faz o mesmo, mas refletido. Ele também cria uma transação de compromisso, a partir da qual ele envia seis bitcoins para si mesmo e quatro para um novo endereço multisig. Alice pode desbloquear este endereço se ela aguardar mais 1000 blocos, ou Bob pode desbloqueá-lo com Alice usando seu segredo.
Bob assina essa metade e dá a Alice.
Depois de toda essa troca de transações de compromisso e segredos, ambos assinam e transmitem a transação de abertura, para garantir que esta seja registrada na blockchain. O canal está agora aberto oficialmente.
Neste ponto, Alice e Bob poderiam assinar e transmitir a transação de compromisso que obtiveram do outro. Se Alice faz, Bob recebe seis bitcoins imediatamente. Se Bob faz, Alice recebe quatro bitcoins imediatamente. Mas quem assina e transmite a transação terá que aguardar 1000 blocos para desbloquear o endereço multisig subseqüente e reivindicar os bitcoins restantes.
Atualizando o Canal
Um pouco mais tarde, Bob quer enviar um Bitcoin para Alice. Eles querem atualizar o estado do canal, para tornar o equilíbrio cinco e cinco novamente. Para fazer isso, Alice e Bob fazem duas coisas.
Primeiro, ambos repetem o processo conforme descrito acima (exceto que a transação de abertura já está registrada na blockchain: essa parte é ignorada). Desta vez, Alice e Bob atribuem-se cinco bitcoins, e ambos atribuem cinco bitcoins aos endereços multisig. As condições para esses endereços multisig são semelhantes, exceto que eles exigem novos segredos: Alice e Bob fornecem-se com novos hashes. Ambos assinam sua nova transação de compromisso meio válida e entregam um ao outro.
Em segundo lugar, Alice e Bob se entregam seus primeiros segredos, como usado na primeira vez.
Neste ponto, novamente, Alice e Bob podem assinar e transmitir a nova transação de compromisso que acabaram de receber. Sua contraparte receberia cinco bitcoins imediatamente, enquanto o apresentador deveria aguardar 1000 blocos. Como tal, o canal é atualizado.
Mas o que está impedindo Bob de transmitir a transação de compromisso mais antiga? Essa transação de compromisso levou a um caminho que lhe pagou seis bitcoins, em vez de cinco …
O que está parando Bob, é claro, é o seu primeiro segredo, que ele já deu a Alice.
Bob não pode assinar e transmitir com segurança a transação de compromisso mais antiga, porque Alice agora conhece o primeiro segredo de Bob. Se Bob assinasse e transmitisse essa transação de compromisso, ele enviaria imediatamente quatro bitcoins para Alice … e ele teria que esperar 1000 blocos para reivindicar seus próprios seis bitcoins. Isso é um problema, porque agora que Alice conhece seu segredo, ela poderia usar esse tempo para derrotar Bob e reivindicar os outros seis bitcoins também!
E como Bob também tem o segredo de Alice, isso é tão verdadeiro para o outro lado. Se Alice tenta assinar e transmitir uma antiga transação de compromisso, Bob pode roubar todos os bitcoins no canal.
Isso, é claro, significa que Alice e Bob estão fortemente incentivados a jogar de forma justa e apenas assinar e transmitir o estado mais recente do canal.
*Texto escrito por Aaron van Wirdum.
Continue para a segunda parte:
Entendendo a Lightning Network, Parte 2: Criando a Rede
