Em 6 de setembro, exatamente 3.996,01834922 $BTC deixaram a reserva da Federação Liquid.
Naturalmente, os primeiros títulos fizeram isso soar como algum tipo de hack de Bitcoin.
Não foi.
O Bitcoin L1 não foi comprometido.
De acordo com a declaração oficial da SideSwap, o atacante primeiro criou L-BTC na Liquid por meio de um bug no software Elements e depois passou esse L-BTC por aquilo que parecia ser um processo normal de peg-out.
A federação considerou o peg-out como válido e pagou BTC real na rede principal do Bitcoin.
https://x.com/liquid_btc/status/2096696272447218108
Então alguém não hackeou o Bitcoin diretamente.
O software por trás da sidechain federada do Bitcoin permitiu que L-BTC inválido parecesse L-BTC real.
E porque a federação acreditava que esses ativos tinham sido queimados de forma legítima, ela liberou um BTC real da reserva.
Essa diferença é, basicamente, toda a história.
Os blocos do Bitcoin, mineradores, consenso, criptografia e carteiras L1 normais não foram comprometidos.
O que foi afetado foi a Liquid.
L-BTC, a infraestrutura de peg e a capacidade de mover ativos pela rede eram o problema real.
O que sabemos e o que ainda não sabemos
O que sabemos:
➛ Cerca de 4.000 BTC saíram da reserva da Liquid Federation
➛ “a mainnet do Bitcoin foi hackeada” é falso
➛ A SideSwap diz que sua chave PAK e sua infraestrutura não foram roubadas
https://x.com/side_swap/status/2096709838310928674
➛ O problema veio de um bug no Elements
➛ As operações da Liquid foram interrompidas
O que ainda não sabemos:
➛ Se todos os fundos serão devolvidos
➛ o total exato de L-BTC sem lastro criado
E eu acho que manter esses dois grupos separados importa aqui.
Já existe muita especulação sobre o bug exato. Mas até termos um post-mortem técnico adequado, alguns desses detalhes ainda são apenas teorias.
Primeiro, o que é a Liquid?
Vamos deixar a configuração simples primeiro.
O Bitcoin é extremamente seguro, mas o próprio Bitcoin não foi projetado para fazer todas as coisas financeiras que as pessoas querem fazer com BTC.
A Liquid é uma rede separada rodando junto com o Bitcoin.
Uma sidechain.
Ao contrário do Ethereum ou de outras redes abertas de validadores, no entanto, a Liquid é gerenciada por um grupo de participantes institucionais chamado Liquid Federation.
O fluxo básico do usuário parece assim:
Você envia BTC para dentro da Liquid. Esse BTC fica travado na reserva da mainnet do Bitcoin da federação.
Você recebe L-BTC na Liquid.
Você pode usar esse L-BTC dentro da Liquid para transferências mais rápidas, transações confidenciais ou outros produtos.
Quando você quer BTC de volta, o L-BTC é queimado e a federação libera BTC de sua reserva na mainnet do Bitcoin.
A Liquid protege essa reserva de BTC usando um multisig 11-de-15.
Pelo menos 11 dos 15 funcionários/função devem assinar antes que o BTC possa sair da reserva.
Parece bem forte.
E para segurança de chaves, é.
Mas este incidente mostra por que só a segurança de chaves não é suficiente.
Você não precisa roubar 11 chaves se todos os 11 signatários honestos estiverem recebendo as mesmas informações erradas.
Se o software disser a todos “esta retirada é válida”, assinaturas honestas ainda podem aprovar um pagamento ruim.
Isso é bem mais interessante para mim do que simplesmente dizer “o multisig falhou.”
Então o que realmente aconteceu?
1. Um bug no Elements fez L-BTC inválido parecer válido
A Liquid roda em um software open-source chamado Elements.
O Elements adiciona coisas como transações confidenciais, ativos confidenciais e o peg bidirecional federado em cima de uma infraestrutura parecida com a do Bitcoin.
A declaração da SideSwap é bem clara nesta parte:
O L-BTC usado no peg-out havia sido criado devido a um bug no software Elements.
Em outras palavras, o atacante tinha L-BTC que não deveria ter existido.
Isso não foi uma situação de roubo de senha de carteira.
Era um problema de validação.
A rede aceitou como válido algo que não deveria ser válido.
O mecanismo técnico exato do bug ainda não foi publicado em um post-mortem oficial completo.
Há alegações sobre coisas como cache de rangeproofs e componentes de transações confidenciais, mas eu não trataria nenhuma delas como confirmada até que a Blockstream ou a Liquid publique a decomposição técnica.
2. O atacante enviou 4.000 L-BTC para o peg-out da SideSwap
De acordo com a SideSwap:
6 de setembro, 14:05 UTC
Um cliente enviou 4.000 L-BTC para o serviço de peg-out da SideSwap.
Do ponto de vista do sistema, parecia um pedido normal.
O L-BTC foi queimado.
A autorização do peg-out parecia válida.
PAK, ou Peg-out Authorization Key (Chave de Autorização de Peg-out), é basicamente outro controle que limita quais endereços de Bitcoin podem receber peg-outs.
E este é outro ponto importante:
A chave PAK não foi roubada.
A Liquid e a SideSwap disseram que a chave PAK e outras chaves de assinatura não foram comprometidas.
Então, de novo, o problema não foi alguém roubando as chaves e forçando o sistema a enviar BTC.
O próprio sistema acreditou que a retirada era legítima.
3. Depois, o BTC real saiu da reserva da federação
Às 14:28 UTC, a Liquid Federation pagou exatamente:
na mainnet do Bitcoin.
Você pode verificar a transação do Bitcoin aqui: https://mempool.space/tx/8db751a650ae2f12006b7e8c69a75e4df360e8afd6b9e05ae0b9fa6458a7b140
E o peg-out da Liquid relacionado aqui: https://blockstream.info/liquid/tx/ce4caece413cd9d444ce7ed9f54e5b328b3da5e4af301aff59a3571f76e988f2
Então, quando as pessoas dizem “4.000 BTC”, elas estão arredondando.
O pagamento verificável do Bitcoin foi de 3.996,01834922 BTC, valendo cerca de US$ 318–320M na época.
Este é BTC real que saiu do fundo/caixa de reserva da federação.
Essa parte não é teórica.
4. A Liquid parou
Após o incidente, a Liquid desabilitou nós de bridge e interrompeu novas transações.
As corretoras também começaram a suspender depósitos e saques de L-BTC.
Então isso não era apenas um problema de contabilidade de reservas.
Se você realmente estivesse usando a Liquid, sua capacidade de transferir, trocar (swap), fazer peg in ou peg out também foi afetada.
5. O atacante diz que são whitehats
Há também esta parte.
O atacante deixou uma mensagem no Bitcoin:
“somos whitehats. contatem-nos on-chain.”
Mas dizer que você é um whitehat não faz de você um.
Ainda não, pelo menos.
Até que os fundos sejam de fato devolvidos, a vulnerabilidade seja divulgada de forma responsável e os danos sejam resolvidos; eu acho que a descrição mais segura é simplesmente esta:
O atacante afirma que é um whitehat.
Os fundos não foram confirmados como devolvidos.
Então, por enquanto, ainda é um incidente de segurança grande e não resolvido.
Por que o Bitcoin não foi hackeado?
Porque, do ponto de vista do Bitcoin, nada inválido aconteceu.
A transação tinha as assinaturas necessárias.
Mineradores viram uma transação válida do Bitcoin.
O consenso do Bitcoin aceitou isso.
Ninguém quebrou a Prova de Trabalho.
Ninguém quebrou a criptografia do Bitcoin.
Ninguém alterou o limite de oferta de 21M.
O Bitcoin não tinha como saber que a contabilidade dentro da Liquid estava errada.
Pense nisso como um banco.
Imagine que um banco tem um cofre onde retiradas exigem múltiplas assinaturas autorizadas.
O sistema interno do banco diz, por engano, a esses signatários que um cliente realmente possui US$ 100M.
Eles aprovam a transferência.
O cofre em si não falhou.
O processo de autorização recebeu informações incorretas.
Basicamente, essa é a diferença aqui.
Então:
“O Bitcoin foi hackeado” está errado.
“O peg federado da Liquid sofreu uma grande falha de segurança” está muito mais perto do que realmente aconteceu.
E é aqui que a história fica mais interessante
Para mim, a lição maior não é realmente sobre a Liquid especificamente.
É o que acontece toda vez que pegamos BTC e o tornamos mais utilizável em outro lugar.
BTC nativo na sua própria carteira depende principalmente das suposições de segurança do próprio Bitcoin.
L-BTC depende de mais coisas.
Consenso do Bitcoin + software da Liquid
Prova de Trabalho + confiança na federação
Suas chaves + o mecanismo de peg
Validação de ativos da Liquid
E a federação gerenciando corretamente a reserva de BTC.
Isso não significa automaticamente que L-BTC é inseguro.
Isso só significa que o modelo de risco é mais amplo.
Cada bridge, sidechain, produto de BTC envolvido (wrapped) ou custodiante adiciona algo útil.
E, geralmente, também adiciona outra coisa que precisa funcionar corretamente.
11-de-15 parece seguro. Mas o que exatamente os 11 estão assinando?
Essa provavelmente é a minha parte favorita do incidente.
Quando as pessoas pensam em segurança de multisig, a pergunta geralmente é:
Quantas chaves um atacante precisaria roubar?
11-de-15 parece forte porque roubar 11 chaves de assinatura independentes obviamente é difícil.
Mas, de acordo com a explicação oficial atual, isso não aconteceu aqui.
Os signatários aparentemente foram apresentados a um estado que parecia válido.
Então talvez a pergunta mais importante seja:
O que esses 11 signatários realmente estão verificando?
E todos os 11 dependem da mesma lógica de software?
Porque se cada signatário tiver, independentemente, uma chave segura, mas cada signatário confia na mesma lógica de validação quebrada, então a diversidade de chaves não necessariamente te dá diversidade de validação.
Esse é um tipo de risco bem diferente.
E é algo que as pessoas discutem muito menos.
Até prova de reservas fica mais complicada
Normalmente, a pergunta óbvia para algo como L-BTC é:
A quantidade de BTC que está na reserva corresponde à quantidade de L-BTC em circulação?
Faz sentido.
Mas sistemas de transações confidenciais tornam isso mais difícil porque as quantidades de tokens nem sempre podem ser vistas publicamente do mesmo jeito simples.
E há outro problema.
Se L-BTC inválido puder ser criado e depois queimado no mesmo processo que retira um BTC real, um snapshot básico feito depois pode não contar toda a história histórica.
Você poderia potencialmente olhar o sistema depois do evento e não perceber como a divergência aconteceu.
Mas eu não quero ir além das evidências aqui.
Esta não é uma decisão final sobre o design de reservas da Liquid.
É um problema de reconciliação exposto pelo incidente.
Precisamos do relatório técnico completo, reconciliação das reservas e contabilidade completa de emissão/queima antes de fazer alegações mais fortes.
Isso é sistêmico para o Bitcoin?
Não acho que sim.
Cerca de 4.000 BTC é uma quantia enorme.
Mas, em relação ao próprio Bitcoin, não é um choque sistêmico de oferta.
A segurança do protocolo do Bitcoin também não foi afetada.
Então eu não transformaria isso numa história de mercado do tipo “o Bitcoin está quebrado”.
Mas para a infraestrutura que está sendo construída em volta do Bitcoin?
Sim, isso importa.
Especialmente quando o BTC é envolvido, interligado, guardado (custodiado) e financeirizado em mais sistemas.
Existe também outra distinção em relação a outros ativos da Liquid.
A Liquid disse que ativos como USDT, DePix e RWAs não foram comprometidos diretamente pelo incidente de segurança.
Mas “não comprometido diretamente” não significa “totalmente não afetado”.
Se a rede estiver parada, você ainda pode ter problemas de transferência e liquidez mesmo que o token em si não tenha sido hackeado.
Então quem precisa realmente se importar?
Se você mantém BTC nativo na sua própria carteira
Este incidente não afeta diretamente a segurança do seu protocolo.
O Bitcoin L1 não foi comprometido.
Se você detém L-BTC
Você tem exposição operacional ao peg, às transferências e ao restart/reinício da rede da Liquid.
Peg-outs, swaps e transferências sendo interrompidos obviamente importam.
Se você detém USDT ou ativos tokenizados na Liquid
Não há confirmação de que esses próprios ativos foram hackeados.
Mas se a Liquid não estiver operando normalmente, acesso e liquidez ainda podem se tornar um problema.
Se você usa um produto construído sobre a Liquid
Então eu me preocuparia com o quanto exatamente esse produto depende da Liquid, qual colateral ele usa e como fica o plano de recuperação/restart.
Meu ponto de vista
Isso não foi um hack do Bitcoin.
E eu acho que descrevê-la assim realmente esconde a lição mais útil.
Um bug de software no Elements permitiu que L-BTC sem lastro passasse por um fluxo de peg-out que parecia legítimo.
A Liquid Federation então pagou 3.996 BTC na mainnet do Bitcoin.
As chaves aparentemente não foram roubadas.
As assinaturas funcionaram.
O Bitcoin funcionou.
O problema era que o que estava sendo assinado parecia válido quando não deveria.
E isso muda bastante a questão de segurança.
Não é só:
quantas chaves protegem a reserva?
É também:
que informação essas chaves estão confiando antes de assinarem?
O Bitcoin pode ser extremamente seguro enquanto algo construído sobre o Bitcoin ainda falha.
Toda vez que envolvemos BTC, fazemos bridge, custodiamos ou movemos para outro ambiente de execução, ganhamos mais usabilidade.
Mas nós também adicionamos outra suposição de confiança.
Essa é a história real aqui