A 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.
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.
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.
É 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.
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.
