Visualizando Contratos Hash-Time-Lock (HTLCs) e o pequeno segredo sujo da Lightning Network

Um canal Lightning pode ser pensado como uma sequência de contas esticadas entre duas pessoas. Consultando a Fig. 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 por meio 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 Lightning Network — é que as contas podem se mover de um lado para o outro, mas não podem sair do cordão em que estão.

Fig. 1. Alice pode enviar um pagamento para Carol roteando-o por Bob. Como as contas não podem sair do cordão em que estão, Bob acaba com uma conta a mais em seu cordão com Alice e uma conta a menos em seu cordão com Carol.

Isso é tudo que você precisa saber para entender como o dinheiro pode fluir na Lightning Network. No entanto, esse modelo não nos diz nada sobre por que os pagamentos na Lightning são seguros. Por exemplo, o que impede Bob de simplesmente manter a conta que Alice empurrou para ele e nunca enviar uma para Carol? O objetivo deste artigo é responder à pergunta "o que torna os pagamentos na Lightning 'sem confiança'?"

Ao final do artigo, revelaremos o sujo segredinho da Lightning Network: que os pagamentos pequenos não são realmente "sem confiança" — nós nós de roteamento podem perder fundos dos clientes.

Contratos Hash-Time-Lock (HTLCs)
Para explicar o que impede Bob de manter a conta de Alice sem enviá-la para Carol, precisamos introduzir "travas" em nossa analogia física para os canais Lightning. Travas podem ser colocadas nos cordões para restringir o movimento das contas e só são abertas se condições específicas forem atendidas. Os contratos hash-time-lock (HTLCs) usados nos pagamentos Lightning envolvem dois tipos de travas (cf. Fig. 2): a primeira é uma trava que se abre se apresentada com a senha correta (vamos chamá-la de "hash-lock"), e a segunda é uma trava que se abre automaticamente após um atraso de tempo (vamos chamá-la de "time-lock").

Fig. 2. O hash-lock se abre quando uma senha é inserida e gera o valor especificado (45f8 neste caso). O time-lock se abre após o tempo especificado ter decorrido (48 horas neste caso).

Agora, voltemos ao pagamento de uma conta de Alice para Carol por meio de Bob. Para tornar o pagamento "sem confiança", Alice, Bob e Carol precisam estar online ao mesmo tempo e participar de um elaborado ritual.

Primeiro, Alice pede a Carol que pense em uma senha secreta e diga a ela o hash da senha. Vamos fingir que a senha que Carol inventou foi "boondoggle" e seu hash foi "45f8". Em seguida, Alice coloca um hash-lock entre ela e Bob, configurado para abrir quando apresentado com uma senha que gera o hash "45f8". Neste ponto, nem Alice nem Bob podem abrir a trava, pois nenhum deles conhece a senha. Alice então empurra uma conta contra o hash-lock. Por fim, ela coloca um time-lock no lado esquerdo da conta, configurado para abrir automaticamente após 48 horas (Fig. 3).

Fig. 3. Com o conhecimento do hash da senha secreta de Carol, Alice pode configurar um hash-lock para proteger a conta que ela transfere para Bob (para depois encaminhar para Carol). Ela trava a conta com um time-lock para que ela possa recuperá-la caso Bob não conclua o pagamento dentro de 48 horas.

Bob percebe que a conta é dele se conseguir descobrir a senha antes de 48 horas se passarem. Ele também sabe (porque Alice disse a ele) que Carol revelará a senha em troca de uma de suas contas. Para incentivar Carol a agir, Bob coloca o mesmo hash-lock entre ele e Carol, empurra uma de suas contas e então a trava com outro time-lock (Fig. 4). Ele sabe que, para Carol abrir o hash-lock e pegar a conta, ela precisará inserir a senha — à vista de todos — que é a mesma senha que Bob precisa para abrir o hash-lock com Alice.

Fig. 4. Bob percebe que a conta de Alice é dele se Carol revelar sua senha antes de 48 horas. Ele configura o mesmo hash-lock, empurra uma conta em direção a Carol e a trava com um time-lock. A única maneira de Carol pegar a conta de Bob é revelar a senha que Bob precisa para reivindicar a conta de Alice.

Carol, ao ver que a conta está lá para ser pega, insere "boondoggle" na trava (lembre-se de que está à vista de Bob). A CPU da trava confirma que hash("boondoggle") = 45f8, e então se abre. Carol move a conta para o lado dela do cordão (Fig. 5).

Fig. 5. Carol revela sua senha para abrir a trava e pegar a conta.

Com o conhecimento da senha de Carol, Bob desbloqueia sua conta de Alice da mesma forma (Fig. 6). O pagamento está completo.

Fig. 6. Com o conhecimento da senha secreta de Carol, Bob pode agora pegar a conta de Alice, completando assim o pagamento.

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 time-lock expirasse. Na prática, Alice enviaria a Bob um pouco mais do que ela pede a Bob para enviar a Carol, como uma taxa para compensar por esse risco e pelo esforço de Bob. Quando o pagamento estiver completo, Bob terá um pouco mais do que começou, motivando-o assim a concluir o pagamento.

Você também pode se perguntar qual é o propósito dos time-locks. Os time-locks permitem que os participantes recuperem seus fundos se o pagamento falhar. Por exemplo, imagine que Bob se torna não cooperativo depois que Alice transfere sua conta e adiciona os dois locks. O time-lock é o que permite a Alice recuperar seus fundos. Ela só precisa esperar o time-lock expirar. Não há como Bob roubar a conta nesse ínterim, 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.

Leitores interessados podem explorar o que acontece se uma das partes se tornar não cooperativa em diferentes etapas do processo de pagamento do Lightning para se convencer de que nem Alice, Bob, nem Carol estão em risco de perder dinheiro devido às ações de suas contrapartes.

O Sujo Pequeno Segredo da Lightning Network
A Lightning Network tem um sujo pequeno segredo que poucas pessoas conhecem. Para entender qual é o segredo — e suas ramificações para os pagamentos do Lightning — precisamos cavar um pouco mais.

Lembre-se de 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: as moedas de Alice, as moedas de Bob e a moeda "em voo".

Fig. 7. A transação de estado do canal Lightning neste ponto do tempo contém três saídas: as moedas de Alice, as moedas de Bob e as moedas em trânsito.

Aqui está o problema: se o valor em trânsito estiver abaixo do limite de poeira do BTC, então não pode ser representado como uma terceira saída na transação de estado do canal! Portanto, não é possível usar hash- e time-locks 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 string seja constante. Na verdade, há um balde ao lado de cada string rotulado como "Taxa do Minerador" que contém pequenas frações de contas. O valor neste balde é reivindicado pelo minerador que confirma a transação de estado do canal, caso o estado do canal seja empurrado para o blockchain. Frações de contas podem se mover da string para o balde, ou do balde de volta para a string, mas apenas se as pessoas em ambos os lados do canal concordarem.

Em vez de travar o valor em trânsito com hash- e time-locks, para pagamentos pequenos, Alice e Bob simplesmente movem o valor em trânsito para o balde de taxas (Fig. 8). Bob confia que Alice cooperará com ele para retirar o valor em trânsito do balde de taxas quando ele revelar a senha secreta de Carol.

Fig. 8. Se as moedas em trânsito estiverem abaixo do limite de poeira, o mecanismo HTLC não pode ser usado porque a transação de estado do canal não seria minerada se fosse transmitida. Em vez de usar o mecanismo HTLC, as moedas em trânsito são despejadas no balde de "Taxa do Minerador".

Fig. 8. Se as moedas em trânsito estiverem abaixo do limite mínimo ("dust threshold"), o mecanismo HTLC não pode ser usado, pois a transação do estado do canal não seria minerada se transmitida. Em vez de utilizar o mecanismo HTLC, as moedas em trânsito são depositadas no "Miner's Fee" (Taxa do Minerador).

Neste esquema alternativo, Bob transfere o valor em trânsito para um segundo compartimento de taxas que ele compartilha com Carol, prometendo entregá-lo a ela se contar a Bob a senha secreta. Carol revela o segredo a Bob, e juntos movem o pagamento do compartimento de taxas para o lado de Carol. Bob então volta para Alice, conta a ela o segredo de Carol e, se tudo correr bem, Alice coopera com ele para retirar o valor em trânsito do compartimento de taxas e colocá-lo no lado de Bob da sequência.

Ao contrário do esquema HTLC descrito anteriormente, este esquema depende da confiança. Por exemplo, Carol poderia revelar a senha a Bob, que poderia deixar o pagamento no compartimento de taxas e ainda assim ir a Alice e entregar a senha em troca de seu pagamento.

As opções de Carol nesse cenário são limitadas: ou ela não faz nada e aceita a perda, ou ela encerra o canal com Bob. No entanto, encerrar o canal com Bob não a deixa totalmente compensada, pois o valor que ela deveria ter recebido é enviado para um minerador!

Apesar de parecer quebrado, esse esquema realmente funciona razoavelmente bem na prática. Bob não tem um incentivo real para não dar o dinheiro a Carol. Se ele não devolver, ele não ficará em uma situação melhor (o minerador ficará com os fundos extras, não ele) e provavelmente em uma situação pior (Carol provavelmente fechará o canal, já que Bob se mostrou não confiável). O dano que Bob pode causar parece limitado ao valor do pagamento mais o custo de estabelecer um novo canal relâmpago.

Por que isso é significativo
O segredo sujo do Lightning é significativo porque revela como a fricção da Camada 1 (L1) vaza para a L2, forçando soluções complexas e mal compreendidas¹ para o protocolo L2. A solução alternativa neste caso alterou a natureza "sem confiança" dos pagamentos do 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.

Alguém poderia argumentar: "estamos falando apenas de pagamentos pequenos, então quem se importa?" Eu não concordo com esse argumento por duas razões:

• O plano de escalonamento do Core, usando o blockchain como uma camada de liquidação com taxas elevadas, 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 do que seu valor. Com taxas de $100, a maior parte do salário mensal de todo o mundo é "poeira".

• Perder vários pagamentos pequenos em rápida sucessão (por exemplo, devido a um ataque de roteamento no LN) poderia resultar em uma perda significativa.

Imagine um futuro em que a maioria dos pagamentos ocorra na Lightning Network, e as taxas de transação na L1 sejam consistentemente superiores a $100. As saídas de poeira abaixo de $100 na mainchain não têm valor porque custa mais gastá-las do que valem.

Agora a Lightning Network enfrenta o problema de que até mesmo pagamentos de $50 não são "sem confiança". No caso em que $50 estão abaixo do limite de poeira (o que seria uma política razoável considerando que $50 seria economicamente impossível de gastar na L1), então os HTLCs não podem ser usados para proteger o pagamento de $50. Os clientes podem perder pagamentos de $50 sem culpa própria.

No caso em que os desenvolvedores tentam contornar alguma "brecha legal" definindo o limite de poeira como $1 para que os HTLCs ainda possam ser usados, o efeito ainda é uma perda de $50 para o cliente, pois a saída não será economicamente gasta! Os clientes ainda podem perder pagamentos de $50 sem culpa própria.

Alguém poderia argumentar "bem, os nós de roteamento podem perder fundos dos clientes e esses fundos podem ser significativos em um futuro com taxas altas, mas os nós de roteamento são pares, não empresas." Eu também não concordo com isso porque o objetivo principal do roteamento de pagamentos do Lightning é ganhar dinheiro em taxas de transação em troca de empréstimo de liquidez. Já hoje, os desenvolvedores do Lightning abandonaram a ideia de que todos os usuários roteariam pagamentos; agora é incentivado que usuários normais usem canais não divulgados e nunca roteiem.

Em um futuro com altas taxas, um hub tem controle custodial efetivo sobre o dinheiro de seus usuários. Um usuário não pode liquidar no blockchain para recuperar fundos de pagamentos não protegidos por HTLCs. Além disso, se o saldo do usuário estiver na mesma ordem de grandeza das taxas on-chain, o usuário também está preso ao hub. Não vale a pena escapar de um canal "ruim", pois isso custaria ao usuário todo o seu saldo. Hubs também podem bloquear os fundos do cliente indefinidamente, recusando-se a rotear pagamentos a menos que certas condições sejam atendidas (por exemplo, desembrulhar as informações de roteamento de cebola para fins de AML/KYC). A única escolha do usuário é liquidar no blockchain e perder todo o seu dinheiro — o que não é uma escolha real! Hubs também podem roubar seus usuários na forma de taxas exorbitantes. Novamente, o usuário está preso e não tem escolha a não ser pagar se quiser acessar seu dinheiro.

Hubs significativamente conectados na Lightning Network, em um futuro com taxas elevadas na camada base, deveriam ser regulamentados devido ao controle efetivo que possuem sobre os fundos de seus clientes.

Gostaria de propor a hipótese de que o seguinte princípio existe:

Pagamentos na Camada 2, para quantias abaixo do que é economicamente viável na Camada 1, não podem alcançar uma natureza "sem confiança".

A eficácia do Lightning depende da liberdade da blockchain subjacente, alinhando-se com as expectativas dos usuários.

Isso é apenas uma das muitas razões pelas quais um futuro em que a maioria das transações ocorre na Lightning Network e a blockchain possui taxas elevadas será muito diferente do que as pessoas esperam. Outras razões incluem:

• O Lightning dimensiona transações, não usuários. O custo de operar um nó completo de validação ainda será alto.

• A fricção na Camada 1 afeta a fungibilidade na Camada 2; as moedas têm um valor dependente da posição.

• Liquidez: a maioria dos "estados de riqueza" não é alcançável por meio de transações na Lightning. Falhas em pagamentos são inevitáveis.

• Roteamento é difícil se o grafo de rede for extenso: os hubs da Lightning tenderão a se centralizar para reduzir problemas de roteamento e liquidez.

• A experiência típica do usuário ao executar uma carteira não custodial sempre será complicada: os usuários precisam estar online para receber dinheiro, contratar torres de vigilância para monitorar fraudes em canais, assinar serviços de roteamento de origem para enviar pagamentos e fazer backup dinâmico de seus estados de canal contra corrupção de dados.

• Risco sistêmico: uma quantidade muito grande de moedas precisa ser bloqueada em canais da Lightning (carteiras quentes) para fornecer a liquidez necessária.

• As taxas agregadas dos mineradores na Camada 1 não serão suficientes para garantir a segurança da blockchain quando a recompensa por bloco se esgotar.

Esse texto apontar que LN não é “sem confiança” para pequenos pagamentos e que os fundos dos clientes poderiam ser redirecionados para o mineradores sem culpa do cliente. A crença amplamente difundida, mas falsa, dentro da comunidade BTC era que todos os pagamentos Lightning eram “sem confiança” por design .