Imagem da matéria: Entendendo a Lightning Network, Parte 2: Criando a Rede

primeira parte desta série abrangeu a construção dos blocos e explicou como eles são usados para estabelecer canais de pagamento bidireccionais. Esta segunda parte explica como os canais de pagamento bidirecionais são transformados em uma rede.

A Rede

No artigo anterior, Alice e Bob estabeleceram um canal de pagamento bidirecional. Agora, Alice quer pagar um bitcoin a uma terceira pessoa, Carol.

Publicidade

Para fazer isso, Alice e Carol poderiam abrir um canal de pagamento entre eles. Mas eles realmente não precisam. Como aconteceu, Bob e Carol já têm um canal mútuo, então Alice pode simplesmente pagar Carol através de Bob.

Especificamente, Alice pode pagar Bob um bitcoin, e Bob pode pagar Carol um bitcoin.

No entanto, Alice realmente não confia em Bob – ou Carol para esse assunto. Ela tem medo de que, se ela pagar Bob, Bob nunca pagará Carol. Ou talvez Bob pague Carol, mas Carol vai reivindicar que nunca recebeu o dinheiro, e Alice não saberia quem culpar.

Alice, portanto, quer garantir que ela só pague um bitcoin ao Bob, se ele também pagar um bitcoin à Carol. Isso é realizado (em parte) com um truque criptográfico simples.

Quando Alice quer enviar a Carol um bitcoin, ela diz a Carol que crie um ‘valor’ (uma série aleatória de números) e envie-lhe o hash. Alice também diz a Carol que troque o ‘valor’ original com Bob por um bitcoin.

Publicidade

Alice, entretanto, pega o hash de Carol, vai para o Bob e diz a Bob que ela lhe dará um bitcoin se ele lhe fornecer o ‘valor’ correspondente (o que apenas a Carol tem).

Então, Bob volta para Carol, e dá a Carol um bitcoin em troca do ‘valor’.

Então, Bob volta a Alice com o ‘valor’. Alice sabe que Bob deve ter obtido o ‘valor’ de Carol em troca de um bitcoin, e, portanto, conclui que Carol conseguiu seu bitcoin. Então Alice pode confiantemente dar uma chance a Bob.

Todo mundo está feliz.

Bem… quase todos estão felizes.

Neste cenário “ingênuo”, o intermediário Bob ainda precisa confiar em Alice e Carol. Bob tem que confiar em Carol para realmente lhe dar o valor depois que ele lhe enviou um bitcoin, e Bob tem que confiar em Alice para realmente dar-lhe um bitcoin uma vez que ele lhe apresenta o ‘valor’.

As negociações bitcoin-for-value devem, portanto, ser absolutamente garantidas ao longo da rede. Mais especificamente: se Bob dá um bitcoin a Carol, ele deve ser garantido para obter um bitcoin de volta de Alice.

Publicidade

É aí que os Hash Time-Locked Contracts (HTLCs) entram.

Hash Time-Locked Contracts

Então Alice e Bob querem trocar um bitcoin pelo ‘valor’ através de um HTLC. (E Bob e Carol também querem fazer uma troca de bitcoin por esse mesmo valor – mas não se importe com isso por enquanto).

Para fazê-lo, ao invés de enviar Bob um bitcoin diretamente, Alice envia um bitcoin para um novo endereço multisig. Os bitcoins trancados neste endereço podem ser desbloqueados de duas maneiras diferentes.

A primeira opção é que Bob inclua sua assinatura e o ‘valor’.

A segunda opção é que Alice inclua sua própria assinatura. No entanto, esta opção tem um CLTV-timelock sobre ele: Alice pode assinar e transmitir a transação apenas após – digamos – duas semanas passarem.

Isso significa que Bob tem duas semanas para criar uma transação subseqüente na qual ele inclui sua assinatura e o valor, e transmitir para enviar o bitcoin do endereço multisig para si mesmo. Como tal, esta negociação é garantida. Bob só pode reivindicar o bitcoin de Alice se ele fornece o valor: transmiti-lo através da rede Bitcoin tornando publicamente visível para Alice ver.

E se Bob não fornecer o ‘valor’ no tempo certo, os bitcoins voltam para Alice. Simples.

Como mencionado, não só Alice e Bob, mas também Bob e Carol estabeleceram um HTLC. Então, se Carol reivindica seu bitcoin de Bob, Bob obterá o valor em troca; Será visível na blockchain.

Publicidade

Portanto, se isso acontecer, Bob é garantido para obter um bitcoin de Alice também. Bob pode aproveitar o valor que Carol tornou publicamente visível na blockchain e incluí-lo em seu HTLC com Alice e também reivindicar um bitcoin para ele. Os dois canais estão efetivamente vinculados.

Como um detalhe final, é importante que Bob obtenha o valor de Carol antes que Alice possa recuperar o bitcoin de Bob. Se Bob obteve o valor da Carol apenas depois que Alice já recuperou a dela, Bob está preso no meio, depois de tudo. O tempo limite (time-out) no HTLC de Bob e Carol deve, portanto, expirar antes que expire o tempo limite no HTLC de Alice e Bob. (Por exemplo, após exatamente dez dias, em vez de duas semanas. É também por isso que os HTLCs precisam de CheckLockTimeVerify (CLTV) – e não CheckSequenceVerify (CSV).)

 

Continue para a Terceira parte:

Entendendo a Lightning Network, Parte 3: Fechando o Canal

 

*Texto escrito por Aaron van Wirdum.

Talvez você queira ler
Tela de computador que mostra moeda de bitcoin em meio a traços matrix

Investidor que pagou a taxa de Bitcoin mais cara da história revela ter sido vítima de hacker

“Hackers pagaram taxa de 83,5 BTC com meu dinheiro”, denuncia investidor
Bonequinho em cima de uma pilha de moedas douradas de bitcoin fazendo alusão ao processo de mineração

Censura no Bitcoin? Grande pool de mineração revolta comunidade ao “filtrar” transações suspeitas

Um desenvolvedor do Bitcoin detectou seis transações perdidas de endereços sancionados pelo governo dos EUA
Máquinas de mineração de Bitcoin Micro BT modelo Whatsminer S30

Receita Federal confisca máquinas de mineração de Bitcoin em aeroporto avaliadas em R$ 43 mil

Brasileiro tentava pegar um avião no aeroporto de Foz do Iguaçu com quatro mineradoras de Bitcoin adquiridas no Paraguai
Udi Wertheimer, da Taproot Wizards fantasiado de mago

Como a Taproot Wizards planeja ‘finalmente mover o Bitcoin para frente’

O cofundador da Taproots Wizards, Udi Wertheimer, comenta a iniciativa que vai impulsionar a cultura do Bitcoin