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.

VOCÊ PODE GOSTAR
Imagem da matéria: Por que o Bitcoin está menos vulnerável à "guerra de tarifas" de Trump

Por que o Bitcoin está menos vulnerável à “guerra de tarifas” de Trump

O ultimato do presidente Trump antes do Super Bowl quase não afetou o preço do Bitcoin, que abriu a semana em alta
moeda de bitcoin desfocada

“Para que serve o Bitcoin?”: a resposta que o mercado já deu | Opinião

Fabricio Tota traz uma análise com fatos, dados e reflexões essenciais para o debate sobre a utilidade do Bitcoin
Pai Rico Pai Pobre Robert Kiyosaki posa para foto

“Possuir Bitcoin é mais inteligente e seguro do que economizar dólares”, diz Pai Rico

O autor do best-seller mundial “Pai Rico, Pai Pobre” explicou por que comprou mais ouro e Bitcoin
moeda de bitcoin em cima de tela com gráfico de preço

Bitcoin reage bem ao relatório de empregos nos EUA, mas volatilidade segue alta

Dados mostram que desemprego nos EUA caiu 4% e Bitcoin recuperou por instantes a faixa de US$ 100 mil