💻 computer science

Enabling Threshold Custody for the Lightning Network with Nested Threshold Multi-Signatures

Este artigo apresenta o "Iceberg", uma nova construção criptográfica para assinaturas MuSig2 de limiar aninhado que permite que um lado de um canal da Lightning Network do Bitcoin opere como um grupo de limiar $t$ -de- $n$ seguro sem exigir quaisquer modificações no protocolo subjacente, no Bitcoin ou nos contrapartes, enquanto mantém uma alta taxa de processamento de pagamentos.

Autores originais: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Publicado 2026-08-24

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Paul Gerhart, Nadav Kohen, Jesse Posner, Matias Furszyfer

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

No mundo digital do Bitcoin, o dinheiro se move através de duas camadas distintas. A camada principal, conhecida como blockchain, é um livro-razão público onde as transações são registradas permanentemente. Sobre ela, reside a Lightning Network, um sistema mais rápido e privado projetado para lidar com milhares de pagamentos por segundo sem sobrecarregar o livro-razão principal. Para usar este sistema, duas pessoas abrem um canal privado entre si, travando seus fundos sob uma trava digital especial que exige a aprovação de ambos para gastar. Esta configuração tornou-se vital para grandes instituições financeiras, lidando com centenas de milhões de dólares em valor. No entanto, uma fraqueza crítica persistiu desde a criação da rede: as chaves digitais que controlam esses fundos em cada lado do canal são mantidas por um único dispositivo. Se esse único dispositivo for roubado, hackeado ou simplesmente perdido, os fundos desaparecerão para sempre. Não há backup, não há recuperação e não há forma de dividir a autoridade entre várias pessoas ou máquinas.

Durante anos, especialistas souberam que a solução reside na "custódia de limiar" (threshold custody), um método onde um grupo de pessoas deve concordar em assinar uma transação, mas nem todos os membros precisam estar presentes. Esta é uma prática padrão para proteger grandes somas na blockchain principal, mas era impossível aplicá-la à Lightning Network. A razão é um impasse técnico: a Lightning Network exige um aperto de mão específico e rígido entre duas partes para atualizar os saldos, e este aperto de mão não permite que um dos lados revele subitamente que é, na verdade, um grupo de pessoas. Se um dos lados tentasse usar uma chave de grupo, isso quebraria o protocolo, forçando a outra pessoa a alterar seu software ou toda a rede a se adaptar. Isso deixou a Lightning Network vulnerável, dependendo de pontos únicos de falha frágeis, enquanto o resto do mundo financeiro se move em direção a uma segurança mais robusta e distribuída.

Uma equipe de pesquisadores resolveu agora este problema ao inventar um novo método criptográfico chamado Iceberg. O trabalho deles permite que um lado de um canal Lightning opere como um grupo seguro de signatários enquanto aparece para o outro lado como um usuário único e comum. Imagine um cofre de banco que requer três gerentes para abrir, mas, para o mundo exterior, parece que uma única pessoa está girando a chave. Os pesquisadores alcançaram isso criando um sistema onde o acordo interno do grupo acontece invisivelmente, nos bastidores, sem nunca alterar as mensagens enviadas à contraparte. O resultado é uma forma de distribuir o risco e evitar a perda total sem exigir quaisquer mudanças na rede Bitcoin, no protocolo Lightning ou no software usado pela outra pessoa no canal.

O cerne da inovação reside em como o grupo lida com os "nonces" digitais, que são números aleatórios usados para criar uma assinatura. Na Lightning Network, esses números devem ser acordados antes mesmo que os detalhes específicos da transação sejam conhecidos. Isso cria um desafio único: se o grupo mudar seus membros entre o momento em que o número é escolhido e o momento em que a transação é assinada, a assinatura poderá falhar ou tornar-se insegura. Tentativas anteriores de resolver isso exigiam que todos os membros estivessem online ao mesmo tempo ou forçavam o grupo a revelar sua estrutura interna. O sistema Iceberg supera isso usando uma técnica chamada compartilhamento secreto replicado (replicated secret sharing). Nesta configuração, cada membro do grupo detém uma parte da chave secreta, mas as peças são organizadas de modo que qualquer pequena maioria do grupo possa reconstruir os números necessários, independentemente de quem esteja online no momento. Crucialmente, o sistema deriva esses números de uma forma que depende apenas do estado do canal, não de quais membros específicos estão presentes. Isso significa que, se alguns membros ficarem offline ou se a composição do grupo mudar, os membros restantes ainda podem produzir exatamente a mesma assinatura que foi prometida anteriormente, mantendo o canal seguro e funcional.

Para provar que este conceito funciona no mundo real, os pesquisadores construíram um protótipo funcional e o integraram a um nó de produção da Lightning, um software usado para rotear pagamentos. Eles testaram o sistema sob várias condições, simulando grupos de diferentes tamanhos e tolerando diferentes números de membros defeituosos ou ausentes. Os resultados mostraram que o novo método adiciona apenas um tempo ínfimo ao processo de pagamento. Para um grupo projetado para tolerar um membro corrompido, o tempo extra necessário foi de apenas 3,8 milissegundos por pagamento. Isso representa um aumento de meros 6,7 por cento no trabalho computacional já exigido para uma transação padrão. Mesmo com grupos maiores projetados para lidar com mais falhas, o sistema manterou uma alta velocidade, sustentando mais de 93 por cento do rendimento de pagamento de um canal padrão e não modificado. Isso demonstra que a segurança da custódia de limiar pode ser adicionada à Lightning Network hoje, sem sacrificar a velocidade que torna a rede útil.

A segurança deste novo sistema também foi rigorosamente comprovada. Os pesquisadores mostraram que, desde que o grupo tenha uma maioria de membros honestos, é matematicamente impossível para um atacante forjar uma assinatura ou roubar os fundos, mesmo que ele controle alguns dos dispositivos do grupo. A prova leva em conta a realidade complexa da Lightning Network, onde os membros podem ficar offline, as mensagens podem ser atrasadas e o grupo pode precisar concordar com o estado atual do canal antes de assinar. Ao formalizar um novo tipo de primitiva criptográfica chamada "multi-assinaturas de limiar aninhadas" (nested threshold multi-signatures), a equipe forneceu uma garantia matemática de que o grupo atua como uma entidade única e segura. Isso significa que instituições e indivíduos podem agora implantar esta proteção unilateralmente; eles podem atualizar sua própria segurança sem pedir que ninguém mais mude seu software ou sem esperar por uma atualização de toda a rede.

As implicações deste trabalho vão além de apenas corrigir uma vulnerabilidade; elas mudam a forma como pensamos em proteger ativos digitais em um sistema distribuído. Durante anos, a Lightning Network foi vista como uma troca: velocidade e privacidade vinham ao custo de depender de chaves únicas e frágeis. O Iceberg remove essa troca, permitindo que a rede escale com o mesmo nível de segurança que as grandes instituições já exigem para seus ativos on-chain. Os pesquisadores verificaram que seu sistema funciona perfeitamente com o hardware e software existentes, o que significa que a transição para este modelo mais seguro pode acontecer imediatamente. Ao integrar a solução em um nó do mundo real e medir seu desempenho, eles moveram o conceito de uma possibilidade teórica para uma ferramenta prática. As descobertas confirmam que a Lightning Network pode agora suportar o tipo de custódia multipartidária robusta que protege contra roubos e perdas acidentais.

Este avanço não depende de alterar as regras fundamentais do Bitcoin ou da Lightning Network. Em vez disso, funciona ao encaixar um sistema de segurança complexo de múltiplas pessoas dentro da lacuna simples de uma única pessoa que a rede espera. É um lembrete de que, às vezes, as soluções mais eficazes não consistem em construir algo novo do zero, mas em encontrar uma maneira de fazer com que as estruturas existentes suportem mais peso. Os pesquisadores mostraram que, com a abordagem matemática correta, é possível esconder um grupo de guardiões atrás de um único rosto, garantindo que o dinheiro digital que se move à velocidade da luz seja tão seguro quanto as pessoas que o utilizam. O caminho a seguir está agora claro: a tecnologia existe para proteger esses fundos, e a única barreira restante é a decisão de adotá-la.

Resumo Técnico: Habilitando Custódia de Limiar para a Lightning Network com Multiassinaturas de Limiar Aninhadas

1. Declaração do Problema

A rede Lightning do Bitcoin protege centenas de milhões de dólares em valor, mas seu modelo de segurança baseia-se em um fundamento frágil: cada endpoint de canal é controlado por uma única chave online. Isso cria um ponto único de falha, suscetível tanto ao comprometimento (roubo) quanto à perda (inacessibilidade). Embora a custódia de limiar (assinatura t-de-n) seja uma prática padrão para ativos on-chain do Bitcoin para mitigar esses riscos, ela não tem sido passível de implementação prática para canais Lightning.

O obstáculo técnico central é a estrutura do protocolo Lightning, especificamente sua dependência do esquema de assinatura multiassinatura MuSig2 (padronizado no BIP 327). Em um canal Lightning, duas partes (Alice e Bob) bloqueiam fundos sob uma chave agregada. Para atualizar saldos ou fechar o canal, elas devem trocar nonces e assinaturas parciais em um protocolo estrito de duas rodadas.

A Restrição de Nonce: O MuSig2 exige que o nonce da sessão seja fixo na primeira rodada, antes que a mensagem (a transação a ser assinada) seja conhecida.
O Conflito de Limiar: Se uma parte (por exemplo, Alice) for um grupo de limiar, o conjunto de signatários online pode mudar entre a primeira rodada (geração de nonce) e a segunda rodada (geração de assinatura). Esquemas de assinatura de limiar padrão (como o FROST) vinculam o nonce agregado ao conjunto específico de signatários que participam daquela rodada. Se o quorum mudar, o nonce reconstruído diferirá do que Alice prometeu a Bob na primeira rodada, quebrando o protocolo.
Statelessness vs. Segurança: Assinaturas de limiar sem estado (stateless), que derivam nonces deterministicamente da mensagem, não podem ser usadas porque a mensagem é desconhecida durante a primeira rodada. Além disso, signatários totalmente sem estado no Lightning seriam vulneráveis a assinar estados de canal desatualizados, acionando os mecanismos de penalidade da rede (confisco de fundos).

Consequentemente, a comunidade carecia de um método para "aninhar" um grupo de limiar dentro de uma sessão MuSig2 existente sem alterar o protocolo, a contraparte ou a blockchain.

2. Metodologia e Design

Os autores propõem o Iceberg, a primeira construção para assinaturas MuSig2 de limiar aninhadas. O Iceberg permite que um grupo t-de-n ocupe um único slot de signatário em um protocolo MuSig2, parecendo indistinguível de um participante de chave única padrão para a contraparte e para a blockchain.

A solução baseia-se em três decisões de design fundamentais para satisfazer as restrições do ambiente Lightning:

Compartilhamento de Segredo Replicado (RSS): Para garantir que o nonce permaneça consistente independentemente de qual subconjunto de signatários esteja online, o Iceberg utiliza o compartilhamento de segredo replicado em vez do compartilhamento de segredo de Shamir padrão. A chave secreta é dividida em partes para cada subconjunto de $t-1$ membros. Cada membro detém partes correspondentes aos subconjuntos nos quais ele não está. Isso permite que qualquer quorum qualificável ( $2t-1$ membros) reconstrua as mesmas partes de nonce determinísticas sem precisar se comunicar com membros que estavam offline durante a primeira rodada.
Nonces Únicos Pré-Mensagem: Como o nonce deve ser fixo antes que a mensagem seja conhecida, o Iceberg deriva o nonce deterministicamente do identificador da sessão (que inclui o número de compromisso do canal) em vez da própria mensagem. Isso garante que o nonce seja fixo na primeira rodada, mas único para cada atualização de estado do canal, evitando o vazamento de chave que ocorreria se o mesmo nonce fosse reutilizado para diferentes mensagens.
Consenso sobre o Estado Vivo: Para evitar o risco de segurança de assinar duas mensagens diferentes sob o mesmo identificador de sessão (o que vazaria a chave), o protocolo depende da exigência existente do canal Lightning de consenso sobre o número de compromisso atual. O grupo de limiar deve concordar com o estado vivo antes de assinar, garantindo que uma supermaioria honesta ( $n \ge 3t-2$ ) impeça uma minoria corrupta de forçar uma segunda assinatura no mesmo estado.

Fluxo do Protocolo:

KeyGen: O grupo gera uma chave secreta compartilhada usando RSS. A chave pública agregada ocupa o slot do grupo na saída de financiamento.
PreRound (Offline): Antes que a mensagem exista, o grupo computa as partes de nonce baseadas no identificador da sessão. Elas são agregadas em um único nonce de grupo $R_A$ enviado à contraparte.
SignRound (Online): Uma vez que a mensagem e o nonce da contraparte são conhecidos, o quorum online computa assinaturas parciais usando suas partes de chave e partes de nonce. Elas são agregadas em uma única assinatura parcial $s_A$ .
Resultado: A contraparte combina $s_A$ e sua própria $s_B$ para formar uma assinatura MuSig2 válida. A blockchain vê apenas uma assinatura Schnorr padrão sob a chave agregada.

3. Principais Contribuições

Formalização de Multiassinaturas de Limiar Aninhadas: O artigo introduz um novo primitivo criptográfico projetado para aplicar limiar a um participante dentro de um protocolo de multiassinatura existente sem alterar o fluxo de mensagens ou a troca de nonces do protocolo externo.
A Construção Iceberg: Um esquema concreto e comprovadamente seguro de MuSig2 de limiar aninhado. É o primeiro esquema que suporta quorums dinâmicos (onde o conjunto de assinatura pode mudar entre as rodadas) mantendo os requisitos estritos de nonce do Lightning.
Prova de Segurança: Os autores provam a não-falsificabilidade do Iceberg sob o modelo de segurança TS-MS-EUF-CMA. A prova reduz a segurança do Iceberg à segurança do esquema NestedMuSig2 subjacente, demonstrando que a não-falsificabilidade se mantém mesmo se um adversário comprometer até $t-1$ membros e controlar o co-signatário externo.
Integração em Produção: O Iceberg foi integrado ao eclair, uma implementação de nó Lightning de produção. A integração não exigiu mudanças na lógica do canal, no fluxo de mensagens ou no software da contraparte.

4. Resultados e Desempenho

Os autores testaram o Iceberg em um ambiente de produção usando a curva secp256k1 e o nó eclair.

Sobrecarga (Overhead): Aplicar o limiar a um canal incorre em um custo computacional modesto.
- Para uma configuração 2-de-4 (tolerando 1 falha), o custo adicional total por pagamento é de 3,8 ms (especificamente 3.844 µs), o que representa 6,7% do trabalho que um pagamento já custa.
- Para uma configuração 3-de-7 (tolerando 2 falhas), o custo adicional total é de 8,2 ms (especificamente 8.246 µs), representando aproximadamente 14,3% do trabalho de pagamento.
Vazão (Throughput): Um endpoint com limiar sustenta alta vazão. Um grupo 2-de-4 mantém mais de 93% da vazão de pagamento de um endpoint não modificado (aprox. 16,3 pagamentos por segundo em um único núcleo vs. 17,4 para uma chave única).
Escalabilidade: O crescimento do custo é impulsionado principalmente pelo limite de tolerância a falhas ( $t$ ) e não pelo tamanho total do grupo ( $n$ ), desde que $n$ permaneça dentro de limites práticos (por exemplo, uma dezena de dispositivos).
Compatibilidade: O protótipo passou com sucesso em todos os testes de canal existentes do eclair e verificou que o grupo nunca revisa seu nonce mesmo quando o quorum de assinatura muda entre as rodadas, satisfazendo as restrições estritas do protocolo Lightning.

5. Significância e Alegações

O artigo afirma que o Iceberg permite a implantação unilateral de custódia de limiar na Lightning Network hoje.

Sem Mudanças no Protocolo: Ao contrário de propostas anteriores que exigiam mudanças no Bitcoin Script ou no próprio protocolo Lightning, o Iceberg trabalha dentro da especificação MuSig2 do BIP 327 existente.
Sem Mudanças na Contraparte: A contraparte (Bob) e a blockchain veem apenas um participante de chave única padrão do MuSig2. Nenhuma coordenação ou atualização de software é necessária do outro lado do canal.
Praticidade: A sobrecarga de desempenho é baixa o suficiente para que instituições e usuários possam adotar a custódia de limiar imediatamente sem sacrificar a velocidade ou a capacidade da Lightning Network.

Os autores concluem que o Iceberg resolve um problema de longa data na comunidade Bitcoin, demonstrando que o limiar de um canal Lightning é alcançável sem comprometer a eficiência ou as garantias de segurança do protocolo. Eles observam que trabalhos futuros poderiam explorar a renovação proativa de partes ou a mudança de membros enquanto um canal está aberto, desde que a chave agregada permaneça constante.