O Channel Jamming é uma ameaça para a Lightning Network do Bitcoin?

(Agradecimentos especiais a Antoine Riard e Gleb Naumenko, cujos pesquisas recentes é a base deste artigo.)

O bloqueio de canal é um dos problemas pendentes da Lightning Network em termos de coisas que podem atrapalhar o sucesso dos pagamentos roteados por ela. É um problema amplamente conhecido entre os desenvolvedores que tem sido entendido desde antes da própria rede realmente entrar em operação na rede principal e começar a processar até mesmo um único satoshi.

Até agora, a questão não teve nenhum efeito negativo na rede, mas ao considerar esse fato, é importante ter em mente que a rede ainda é, no grande esquema das coisas, relativamente pequena. Processadores de comerciantes começaram a apoiá-lo, assim como algumas exchanges e muitos serviços e negócios nativos de Lightning/Bitcoin, mas, na realidade, isso não é muito. A rede ainda é muito pequena, predominantemente usada pelos Bitcoiners, e essa não é uma porção muito grande do mundo.

Ainda mais, a quantidade de Bitcoiners que gastam e usam regularmente seus bitcoins em configurações de comércio é um subconjunto ainda menor desse grupo já pequeno. Só porque os ataques possíveis não estão ocorrendo agora, as pessoas não devem presumir que isso significa que eles continuarão a não ocorrer quando a rede crescer para uma escala maior. Quanto maior for, mais competitivo e adversário se tornará.

O que é interferência de canal?

O conceito básico de interferência de canal é rotear pagamentos por meio de um canal do Lightning que você deseja bloquear de você mesmo para si mesmo e, em seguida, não finalizá-los liberando a pré-imagem para o hash de pagamento no contratos de timelock com hash (HTLCs). A(s) vítima(s) não poderá(ão) remover os HTLCs de seu canal até que o timelock para o reembolso tenha expirado, porque eles não teriam como fazer valer sua reivindicação ao dinheiro devido se a pré-imagem fosse liberada após removê-la. Se você bloquear completamente um canal fazendo isso, esse canal será incapaz de rotear quaisquer pagamentos até que o timelock expire em todos os pagamentos maliciosos.

Existem duas estratégias diferentes que podem ser empregadas aqui para realizar o ataque. Você pode tentar bloquear a quantidade roteável disponível em um canal ou tentar bloquear todos os slots HTLC individuais em um canal. Um canal Lightning pode ter apenas 483 HTLCs pendentes em cada direção que ele pode rotear - isso ocorre porque há um limite máximo de tamanho de quão grande uma transação Bitcoin pode ser. Se você adicionar mais de 483 HTLCs por direção no canal, a transação para fechar o canal, se necessário, será muito grande e não será válida para enviar à rede. Isso tornaria tudo no canal inexequível na cadeia.

Assim, um invasor pode tentar bloquear toda a liquidez em um canal ou tentar bloquear todos os slots HTLC em um canal. Qualquer uma das estratégias tornaria o canal inutilizável, mas o bloqueio de slot geralmente será mais barato do que o bloqueio de quantidade. O invasor precisa ter moedas na rede para realizar esse ataque, portanto, rotear o valor mínimo permitido para um HTCL de capacidade 483 será mais econômico do que tentar bloquear toda a liquidez disponível no canal.

Por que alguém iria querer bloquear um canal de iluminação?

Há muitas razões para realizar este ataque. Em primeiro lugar, uma entidade maliciosa que queira atacar o próprio Bitcoin pode bloquear todos os principais canais no “núcleo” da rede para tornar a maior parte da rede inutilizável para o roteamento de pagamentos, exceto para nós que estão muito conectados uns aos outros. . Isso exigiria muito mais moedas para funcionar nessa escala, mas não é algo que deva ser descontado como uma possibilidade à medida que o Bitcoin cresce e se torna uma alternativa aos sistemas de pagamento e dinheiro sancionados pelo governo.

Em segundo lugar, um nó de roteamento, ou comerciante, pode tentar realizar o ataque a um concorrente para gerar taxas para eles em oposição à concorrência. Um comerciante que vende produtos semelhantes pode bloquear os canais de um concorrente para impedir que os clientes façam compras lá, na esperança de incentivá-los a comprar em sua loja. Um nó de roteamento que tenha conectividade de canal semelhante a outro nó pode bloquear os canais do nó de roteamento concorrente para torná-los inutilizáveis ​​para pagamentos de roteamento. Com o tempo, isso destruiria a reputação desse nó em termos de confiabilidade de roteamento e, devido à conectividade semelhante, tornaria cada vez mais provável que as carteiras dos usuários escolhessem o nó do invasor para rotear pagamentos pela rede.

Esses ataques podem ser ainda mais eficientes em termos de capital para o invasor se eles passarem circularmente por um único canal várias vezes. Se eles estiverem perto o suficiente da vítima na rede, eles podem construir uma rota de pagamento que dê voltas e continue passando pelo canal da vítima. Há limites para a duração de uma rota de pagamento, portanto, isso não pode ser feito infinitamente, mas fazer uma rota de pagamento em loop como essa pode reduzir drasticamente a quantidade de moedas que o invasor precisa para bloquear completamente o(s) canal(is) da vítima.

Mitigação de ataques de interferência de canal

Algumas mitigações básicas e parciais podem ser aplicadas para aumentar o custo para os atacantes e mitigar os danos para as vítimas. O primeiro seria um processo de vários estágios para lidar com HTLCs.

Atualmente, cada HTLC adiciona individualmente uma nova saída na transação de confirmação para o estado atual do canal. Um processo de dois estágios pode criar uma única saída extra na transação de confirmação e, em seguida, ter uma segunda transação após aquela que tem o HTLC real adicionado a ela. Isso permitiria um máximo de 483 multiplicado por 483 slots HTLC por canal (ou 233,289 slots). No entanto, isso realmente não corrige nada por si só e exigiria estender os bloqueios de tempo porque você está adicionando uma transação extra para impor coisas na cadeia e poderia realmente ajudar o invasor mais do que a vítima se eles utilizassem essa nova estrutura de transação e o vítima não. Ela, no entanto, ajudará em combinação com outra técnica explicada momentaneamente.

A segunda seria uma estratégia reativa, onde um nó que foi vítima de interferência pode simplesmente abrir um novo canal para o mesmo par que está sendo bloqueado. Isso, no entanto, exigiria capital extra para fazer isso, não corrige o custo de oportunidade de ter o outro canal bloqueado e perder receita de taxas, e o novo canal também pode ser bloqueado posteriormente se o invasor tiver capital disponível para fazê-lo .

A terceira técnica seria agrupar slots HTLC. Atualmente, existem 483 slots, e este é um limite de slot único aplicado universalmente a todos os pagamentos, independentemente do valor do pagamento. Os nós poderiam criar buckets separados de limites de slots menores e aplicá-los a pagamentos de valores diferentes, ou seja, pagamentos de 100,000 sats ou menores só poderiam ter acesso a 150 slots. Assim, o roteamento de pagamentos de menor valor não pode consumir todos os slots HTLC disponíveis.

Pagamentos de 100,000 sats a 1 milhão de sats poderiam ter acesso a 300 slots, e 1 milhão de sats a 10 milhões de sats poderiam ter acesso aos 483 slots completos. Isso aumentaria significativamente o custo de capital de um invasor para o congestionamento de slots, pois eles não seriam mais capazes de consumir todos os 483 slots com o menor valor de pagamento possível. Além disso, como as saídas HTLC abaixo do limite de poeira (atualmente, 546 sats) não podem nem ser transmitidas e aplicadas na cadeia, qualquer coisa abaixo desse limite pode ser tratada como um “balde 0”, já que nenhuma saída HTLC é criada de qualquer maneira. Os nós podem simplesmente impor limites a essas transações com base nos recursos de CPU usados ​​ou em outras métricas para evitar que se tornem riscos de negação de serviço, dependendo de quanto eles podem perder se não forem liquidados honestamente.

O agrupamento de slots em combinação com o manuseio HTLC de dois estágios pode ser usado para otimizar a aplicação de limites HTLC, ou seja, pagamentos de maior valor podem usar a estrutura de dois estágios para criar mais slots para eles por canal, pois o valor de pagamento mais alto aumenta o custo de bloqueando-os para um invasor, tornando menos provável o abuso de um limite de slot mais alto para realizar o bloqueio de invasores.

Em sua pesquisa citada acima, Riard e Naumenko mostraram que com a combinação ideal de slots de bucketing e extensão de slot de dois estágios, a causa do bloqueio de slot pode ser tão cara quanto o bloqueio de quantidade. Isso não resolveria o problema de forma abrangente, mas aumentaria o custo mínimo de execução do ataque se amplamente implementado por nós em toda a rede.

As duas soluções abrangentes que eles analisaram são uma taxa inicial/tempo de espera para bloquear a liquidez e um sistema de reputação usando tokens Chaumian cegos. O TLDR do esquema de taxas é que um título para uma taxa inicial seria pago para rotear um HTLC que deve levar muito tempo para ser liquidado e, quanto mais tempo permanecer indefinido, liberaria uma taxa para cada nó de roteamento por pedaço de tempo que passou sem liquidação. O problema é que impor isso pode levar à necessidade de fechar canais se as taxas não forem enviadas quando necessário, e isso fará com que casos de uso legítimos que exigem longos tempos de bloqueio paguem a mesma taxa mais alta que um invasor que tentar bloquear o canal.

O esquema de reputação envolveria um “título de participação” usando provas de conhecimento zero para provar o controle do Bitcoin como uma defesa Sybil e, em seguida, usar o vínculo vinculado à sua reputação para adquirir tokens Chaumian cegos de nós de roteamento que seriam resgatados e reemitidos em HTLCs estabelecendo-se com sucesso de uma forma que preserva a privacidade. Os nós emitiriam tokens uma vez por identidade e, se um HTLC não fosse liquidado ou reembolsado em tempo hábil, os nós poderiam se recusar a reemitir o token, impedindo assim que um usuário roteasse através de seu nó, a menos que gaste tempo e dinheiro para criar um novo de participação com moedas diferentes a serem emitidas em um novo token.

Para aqueles que desejam ler mais sobre essas duas soluções, mais informações podem ser encontradas nas seções cinco e seis na pesquisa de Riard e Naumenko.

Também vale a pena notar que, se os nós de roteamento adotassem sistemas de custódia baseados em terceiros ou linhas de crédito baseadas em confiança, como escrevi sobre SUA PARTICIPAÇÃO FAZ A DIFERENÇA, todos esses problemas relacionados ao bloqueio de canais deixariam de afetá-los. Isso seria uma grande mudança no modelo de confiança para nós de roteamento, mas teria efeito zero sobre as pessoas que usam canais reais do Lightning para enviar e receber sats, a segurança de seus fundos ou sua capacidade de impor isso na cadeia.

As pessoas podem não querer ouvir isso, mas no final do dia, se as soluções acima para mitigar o congestionamento de canais para canais reais não forem suficientes, esses sistemas de terceiros são sempre uma opção em potencial.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.