Visualizing HTLCs

Visualizando HTLCs e o Segredo Sujo da Rede Lightning

Um canal Lightning pode ser visto como uma série de contas esticadas entre duas pessoas. Referindo-se à Figura 1, Alice pode pagar Bob empurrando uma de suas contas para o lado dele. Se Bob também tiver um canal Lightning com Carol, Alice pode pagar Carol através de Bob: ela empurra uma conta para Bob, que então empurra uma conta para Carol. A regra fundamental – e a razão por trás dos problemas de liquidez da Rede Lightning – é que as contas podem se mover de um lado para o outro, mas não podem deixar a corda em que estão.


Fig. 1. Alice pode enviar um pagamento para Carol passando por Bob. Como as contas não podem deixar a corda em que estão, Bob acaba com mais uma conta em sua corda com Alice e uma conta a menos em sua corda com Carol.
Isso é tudo que você precisa saber para entender como o dinheiro pode fluir na Rede Lightning. Mas esse modelo não nos diz nada sobre por que os pagamentos do Lightning são seguros. Por exemplo, o que está impedindo Bob de simplesmente manter a conta que Alice empurrou para ele e nunca enviar um para Carol? O objetivo deste artigo é responder à pergunta “o que torna os pagamentos do Lightning” sem confiança “?”

No final do artigo, revelaremos o pequeno segredo sujo da Lightning Network: que os pequenos pagamentos não são de modo algum “infiéis” – os nós de roteamento podem perder fundos dos clientes.

Contratos de bloqueio de hash e hora (HTLCs)
Para explicar o que impede Bob de manter a conta de Alice sem enviar uma para Carol, precisamos introduzir “bloqueios” à nossa analogia física para os canais do Lightning. As travas podem ser colocadas nas cordas para restringir o movimento das contas, e somente abertas se condições específicas forem atendidas. Os contratos de bloqueio de hash e tempo (HTLCs) usados ​​nos pagamentos Lightning envolvem dois tipos de bloqueios (cf. Fig. 2): o primeiro é um bloqueio que é aberto se for apresentado com a senha correta (chamaremos isso de hash -lock ”), e o segundo é um bloqueio que se abre automaticamente após um atraso de tempo (chamaremos isso de“ bloqueio de tempo ”).

Fig. 2. O bloqueio de hash abre quando uma senha é inserida e é colocada no valor especificado (45f8 neste caso). O bloqueio de tempo é aberto após o tempo especificado (48 horas, neste caso).
Agora vamos voltar ao pagamento de uma conta de Alice para Carol por Bob. Para tornar o pagamento “sem confiança”, Alice, Bob e Carol precisam estar on-line ao mesmo tempo e participar de um ritual elaborado.

Primeiro, Alice pede que Carol pense em uma senha secreta e diga a ela o hash da senha. Vamos fingir que a senha que Carol inventou era “boondoggle” e seu hash era “45f8”. Em seguida, Alice coloca um hash-lock entre ela e Bob, definido para abrir quando apresentado com uma senha que hashes para “45f8”. Com o tempo, nem Alice nem Bob podem abrir a fechadura porque não sabem a senha. Alice então empurra uma conta contra o bloqueio de hash. Por último, ela coloca um bloqueio de tempo no lado esquerdo do cordão, definido para abrir automaticamente após 48 horas (Fig. 3).

Fig. 3. Com o conhecimento do hash da senha secreta de Carol, Alice pode definir um hash-lock para proteger a moeda que ela transfere para Bob (para depois encaminhar para Carol). Ela bloqueia a moeda com um bloqueio de tempo para que ela possa recuperá-la caso Bob falhe em concluir o pagamento dentro de 48 horas.
Bob vê que a conta é sua, se conseguir descobrir a senha antes de 48 horas. Ele também sabe (porque Alice disse a ele) que Carol revelará a senha em troca de uma de suas contas. Para atrair Carol em ação, Bob coloca o mesmo hash-lock entre ele e Carol, empurra uma de suas contas e, em seguida, prende-a com outro fecho de tempo (Fig. 4). Ele sabe que, para Carol abrir o hash-lock e pegar o talão, ela precisará digitar a senha – à vista – que é a mesma senha que Bob precisa para abrir o hash-lock com Alice.

Fig. 4. Bob vê que a moeda de Alice é dele, se Carol revelar sua senha antes de 48 horas. Ele define o mesmo hash-lock, empurra uma moeda para Carol e a prende com um bloqueio de tempo. A única maneira que Carol pode pegar a moeda de Bob é revelar a senha que Bob precisa para reivindicar a moeda de Alice.
Carol, ao ver que a conta é dela para a tomada, insere “boondoggle” na fechadura (na visão simples de Bob, lembre-se). A CPU da trava confirma que `hash (” boondoggle “) = 45f8` e abre. Carol move a conta para o lado dela da corda (Fig. 5).

Fig. 5. Carol revela sua senha para abrir a fechadura e pegar a moeda.
Com o conhecimento da senha de Carol, Bob desbloqueia sua conta de Alice da mesma maneira (Fig. 6). O pagamento está completo.

Você pode se perguntar por que Bob se incomodaria em participar desse ritual em primeiro lugar. Se Carol não tivesse sido cooperativa, sua conta poderia ter sido congelada até que o tempo limite expirasse. Na prática, Alice enviava a Bob um pouco mais do que ela pede a Bob para enviar a Carol, como uma taxa para compensar esse risco e o esforço de Bob. Quando o pagamento for concluído, Bob terá um pouco mais do que começou, motivando-o a concluir o pagamento.

Você também pode se perguntar qual o propósito dos bloqueios de tempo. Os bloqueios de tempo permitem que os participantes recuperem seus fundos se o pagamento falhar. Por exemplo, imagine que Bob se torne não cooperativo depois que Alice deslocar sua conta e adicionar as duas fechaduras. O bloqueio do tempo é o que permite que Alice recupere seus fundos. Ela só precisa esperar que o bloqueio de tempo expire. Não há como Bob roubar a conta nesse meio tempo, porque ele precisa da senha de Carol, o que ele não pode obter sem dar a Carol uma de suas contas e, assim, completar o pagamento.

Os leitores interessados ​​podem explorar o que acontece se uma das partes não cooperar em diferentes etapas do processo de pagamento Lightning para se convencer de que nem Alice, Bob nem Carol correm o risco de perder dinheiro devido à ação de suas contrapartes.

O Segredo Sujo da Rede Lightning
A Lightning Network tem um pequeno segredo que poucas pessoas conhecem. Para entender o que é o segredo – e suas ramificações para pagamentos Lightning – precisamos nos aprofundar um pouco mais.

Lembre-se que quando Alice enviou o pagamento para Carol através de Bob, o estado intermediário mostrado na Fig. 7 existia. Quando expresso como uma transação de bitcoin, o estado do canal contém três saídas: moedas de Alice, moedas de Bob e a moeda “em voo”.

Fig. 7. A transação de estado do canal Lightning neste momento contém três saídas: moedas de Alice, moedas de Bob e as moedas em voo.
Este é o problema: se o valor em voo estiver abaixo do limite de poeira do BTC, ele não poderá ser representado como uma terceira saída na transação de estado do canal! Portanto, não é possível usar bloqueios de hash e de tempo para proteger o pagamento se o pagamento for muito pequeno.

Para explicar como o LN lida com esse problema, devo primeiro fazer uma confissão. Não é exatamente verdade que o número de contas em uma corda é constante. Na verdade, há um balde ao lado de cada corda chamada “Taxa do mineiro”, que contém pequenas frações de contas. O valor neste intervalo é reivindicado pelo minerador que confirma a transação do estado do canal, caso o estado do canal seja enviado para o blockchain. Frações de contas podem se mover da corda para o balde, ou do balde para a corda, mas somente se as pessoas em ambos os lados do canal concordarem.

Em vez de bloquear o valor em andamento com bloqueios de hash e de tempo, para pequenos pagamentos, Alice e Bob simplesmente movem o valor em movimento para o intervalo de taxas (Fig. 8). Bob acredita que Alice irá cooperar com ele para tirar o valor em voo do orçamento quando ele revelar a senha secreta de Carol.

Fig. 8. Se as moedas em vôo estiverem abaixo do limite de poeira, o mecanismo HTLC não poderá ser usado porque a transação do estado do canal não será minerada se for transmitida. Em vez de usar o mecanismo HTLC, as moedas em voo são despejadas no balde “Taxa do mineiro”.
Bob, em seguida, despeja o valor em vôo em um segundo pacote de taxas que ele compartilha com Carol, prometendo dar a ela se ela disser a senha secreta a Bob. Carol conta a Bob o segredo, e Bob e Carol juntos transferem o pagamento do depósito para o lado de Carol. Bob então volta para Alice, conta o segredo de Carol e, se tudo correr bem, Alice coopera com ele para tirar o valor em vôo do pacote de taxas e colocá-lo no lado de Bob da seqüência.

Ao contrário do esquema HTLC descrito anteriormente, esse esquema depende da confiança. Por exemplo, Carol poderia revelar a senha para Bob, que poderia então deixar o pagamento no depósito e ainda assim ir para Alice e entregar a senha em troca de seu pagamento.

O recurso de Carol nesse cenário é limitado: ela não faz nada e aceita a perda ou fecha seu canal com Bob. Mas fechar o canal dela com Bob não a torna completa, porque o valor que ela deveria ter recebido é enviado para um mineiro!

Apesar de quão quebrado o esquema acima soa, ele funciona razoavelmente bem na prática. Bob não tem incentivo real para não dar o dinheiro a Carol. Se ele não devolver, ele não ficará melhor (o mineiro manterá os fundos extras, não ele) e provavelmente ficará pior (Carol provavelmente fechará o canal, já que Bob provou ser indigno de confiança). O dano que Bob pode fazer aparece limitado ao valor do pagamento mais o custo de estabelecer um novo canal de raio.

Por que isso é significativo?
O pequeno segredo sujo do relâmpago é significativo porque revela como o atrito da Camada 1 (L1) vaza para L2, forçando soluções complexas e mal compreendidas para o protocolo L2. A solução alternativa, neste caso, mudou a natureza “sem confiança” dos pagamentos Lightning: para pagamentos acima do limite de poeira, nem Alice, Bob nem Carol podem perder dinheiro devido às ações de suas contrapartes. Para pagamentos abaixo do limite de poeira, Alice, Bob e Carol podem perder dinheiro sem culpa própria. É um modelo de segurança fundamentalmente diferente do que as pessoas entendiam.

Pode-se argumentar: “estamos falando apenas de pequenos pagamentos, para quem se importa”. Não aceito esse argumento por dois motivos:

O plano de escalonamento de Core de usar o blockchain como uma camada de liquidação de alta taxa aumentará o limite para o que constitui “poeira”. Poeira são saídas que não podem ser gastas economicamente porque a taxa on-chain para gastá-las é maior que seu valor. Com taxas de US $ 100, a maior parte do salário mensal total do mundo é “poeira”.
Perder vários pagamentos minúsculos em rápida sucessão (por exemplo, devido a um ataque de roteamento do LN) pode resultar em uma perda significativa.
Imagine um futuro em que a maioria dos pagamentos ocorra na Lightning Network e as taxas de transação em L1 sejam consistentemente acima de US $ 100. As saídas de poeira abaixo de US $ 100 na cadeia principal não têm valor porque custa mais gastá-las do que valem.

Agora, a Lightning Network tem o problema de que até US $ 50 não são “infiéis”. No caso em que US $ 50 está abaixo do limite de poeira (o que seria uma política razoável considerando que US $ 50 seria economicamente insustentável em L1), as HTLCs não podem ser usadas proteger o pagamento de US $ 50. Os clientes podem perder pagamentos de US $ 50 sem culpa própria.

No caso em que os desenvolvedores tentam contornar o “loop hole” legal definindo o limite de poeira para $ 1 para que as HTLCs ainda possam ser usadas, o efeito ainda é uma perda de US $ 50 para o cliente porque a produção não será economicamente rentável! Os clientes ainda podem perder pagamentos de US $ 50 sem culpa própria.

Pode-se argumentar que “bem, nós de roteamento podem perder fundos de clientes e esses fundos podem ser significativos em um futuro de alta taxa, mas os nós de roteamento são pares e não empresas.” Eu não compro isso porque o propósito de rotear pagamentos do Lightning é ganhar dinheiro em taxas de transação em troca de liquidez de empréstimo. Hoje, os desenvolvedores do Lightning abandonaram a ideia de que todos os usuários iriam rotear pagamentos; Agora, é recomendável que os usuários normais usem canais não anunciados e nunca façam o roteamento.

Em um futuro de alta taxa, um hub tem controle efetivo sobre o dinheiro de seus usuários. Um usuário não pode liquidar no blockchain para recuperar fundos para pagamentos não protegidos por HTLCs. Além disso, se o saldo do usuário for da mesma ordem de grandeza das taxas on-chain, o usuário também ficará preso pelo hub. Simplesmente não vale a pena escapar de um canal “ruim” porque isso custaria ao usuário todo o seu saldo. Portanto, os hubs também podem bloquear os fundos de clientes indefinidamente, recusando-se a rotear pagamentos, a menos que certas condições sejam atendidas (por exemplo, desembrulhando as informações de roteamento de cebola para fins de AML / KYC). A única opção do usuário é se instalar no blockchain e perder todo o seu dinheiro – o que não é uma opção real! Os hubs também podem roubar de seus usuários na forma de taxas exorbitantes. Mais uma vez, o usuário fica preso e não tem outra opção a não ser pagar se quiser acesso ao dinheiro.

Hubs relâmpagos bem conectados em um futuro com taxas elevadas na cadeia devem ser regulamentados, pois eles têm controle efetivo sobre a custódia dos fundos de seus clientes.

Eu gostaria de supor que a seguinte lei existe:

Pagamentos na Camada 2 para valores abaixo do que é economicamente viável para executar na Camada 1 não podem ser feitos “sem confiança”.
O raio só funcionará como as pessoas esperam se o blockchain subjacente não estiver restrito.

Mais
Esta é apenas uma das muitas razões pelas quais um futuro em que a maioria das transações acontece na Rede Lightning e no blockchain tem altas taxas será muito diferente do que as pessoas esperam. Outros motivos incluem:

Relâmpago dimensiona transações, não usuários. O custo para executar um nó de validação completo ainda será alto.
O atrito em L1 afeta a fungibilidade em L2; moedas têm valor dependente da posição.
Liquidez: a maioria dos “estados de riqueza” não é alcançável através de transações Lightning. Falhas de pagamento são inevitáveis.
O roteamento é difícil se o gráfico da rede for grande: os hubs do Lightning serão centralizados para reduzir os problemas de roteamento e de liquidez.
A experiência típica do usuário de administrar uma carteira sem custódia sempre será uma droga: os usuários precisam estar on-line para receber dinheiro, contratar torres de vigilância para monitorar fraudes de canal, assinar serviços de roteamento de origem para enviar pagamentos e fazer backup dinamicamente de seus estados de canal contra corrupção de dados.
Risco sistêmico: uma quantidade muito grande de moedas precisa ser bloqueada em canais Lightning (carteiras quentes) para fornecer a liquidez necessária.

As taxas agregadas do mineiro em L1 não serão suficientes para garantir o blockchain quando a recompensa do bloco se esgotar.
Notas de rodapé
¹ Por exemplo, fui chamado de mentiroso e recebi um feedback duro no Twitter e no Reddit (até mesmo por pessoas que trabalham no LN) por apontar que o LN não é “sem confiança” para pequenos pagamentos e que os fundos dos clientes poderiam ser redirecionados para o mineiros sem culpa do cliente. A crença amplamente difundida, mas falsa dentro da comunidade BTC era a de que todos os pagamentos Lightning eram “sem confiança” pelo design.

Notícias de Informática, Tecnologia, Novidades