✨ Resumo da IA
O 6 de setembro de 2026, uns atacantes aproveitaron un erro de validación no software Elements subxacente á Liquid Network de Blockstream. Acuñaron L-BTC sen respaldo e extraeron uns 319 millóns de dólares (4,000 BTC) sen comprometer as 11 de 15 claves multifirma ou privadas da federación. Os atacantes devolveron uns 85 % (3,400 BTC) como un xesto de white-hat. Conclusión sobre a arquitectura de custodia das plataformas de intercambio de criptomoedas: unha xestión robusta de claves non pode protexer contra unha lóxica de validación e verificación do estado comprometida.
O 6 de setembro de 2026, uns atacantes sacaron aproximadamente 4,000 BTC (uns 320 millóns de dólares) dos sistemas de custodia de Bitcoin deseñados de forma máis conservadora. Os explotadores non descifraron ningunha sinatura nin roubaron ningunha clave. Convenceron a lóxica de validación do sistema de que algo falso era real, e o propio proceso de retirada da federación fixo o resto, en 36 minutos.
Para entender o que isto significa para o futuro da seguridade dos activos dixitais, debemos analizar como se desenvolveu o ataque de Liquid Network e o que revela sobre o deseño da arquitectura de custodia de exchange para 2027.
O que aconteceu realmente: a secuencia de ataques informáticos de Liquid Network por valor de 320 millóns de dólares
Liquid Network é a cadea lateral de Bitcoin de Blockstream, protexida por unha multisinatura de federación de 11 de 15. Require 11 de 15 asinantes aprobados antes de que o bitcoin poida ser vinculado ou retirado á cadea principal de Bitcoin, cunha lista branca de claves de autorización de vinculación (PAK) que restrinxe onde poden ir os fondos. É un deseño realmente forte e, segundo a propia conta de Blockstream, nada diso fallou.
1. A vulnerabilidade (erro de software de Elements)
Os atacantes descubriron un erro de caché de verificación a proba de rango en Elements, o software subxacente que impulsa Liquid Network. O erro permitía que unha saída de transacción non válida omitise as comprobacións coma se xa estivese verificada.
2. The Mint (Creando L-BTC sen respaldo)
Aproveitando o erro da caché, os atacantes acuñaron L-BTC sintéticos sen respaldo sen proporcionar a garantía de Bitcoin requirida.
3. A extracción (retirada mediante intercambio lateral)
Os tokens falsos foron enrutados a través de SideSwap para activar o mecanismo oficial de peg-out da federación. Dado que a transacción cumpría todas as regras de seguridade de alto nivel, a multisinatura (11 de 15) aprobou a retirada, convertendo os tokens falsos en BTC reais na cadea principal en 36 minutos.
4. Negociación e integridade clave
Os atacantes deixaron unha mensaxe na cadea identificándose como whitehats e abriron unha comunicación cifrada con Blockstream. Blockstream verificou que non se viu comprometida ningunha clave de sinatura privada.
5. Recuperación e estado actual
- 7 setembro: Os atacantes devolveron ~3,400 BTC (o 85 % dos fondos roubados, valorados en 260M–272 millóns).
- Fondos restantes: Aproximadamente 598.5 BTC (47 millóns de dólares) permanecen cos atacantes.
- Estado da rede: A partir do 10 de setembro, retomouse a produción en bloques, pero as operacións de entrada e saída fixadas permanecen en pausa durante a restauración do estado.
Tras o ataque de Liquid Network en setembro de 2026, o CEO de Blockstream, Adam Back, declarou que a "paridade LBTC: BTC 1:1" estaría cuberta e aconsellou aos titulares que non vendesen L-BTC no mercado con desconto.
Que é a arquitectura de custodia de Exchange?
A arquitectura de custodia de Exchange é o sistema completo que mantén os activos dos clientes seguros e móbiles. Consta de tres capas distintas, non dúas:
- Capa de xestión de claves: Decide quen pode asinar unha transacción (por exemplo, carteiras quentes, almacenamento en frío, computación multiparte ou multisinatura.
- Capa de autorización: Decide que transaccións asinadas se poden executar baseado en regras e políticas (por exemplo, a lista branca de claves de autorización Peg-out de Liquid).
- Capa de validación: A lóxica subxacente do software que verifica se os activos que se moven son reais e están totalmente respaldados.
A maioría das conversas sobre seguridade das plataformas de intercambio de criptomoedas céntranse nas dúas primeiras. O ataque informático a Liquid Network ocorreu na terceira.
A lección: a xestión de claves non pode protexer un estado non validado
As listas brancas de PAK e as multisinaturas de federación de Liquid son precisamente o tipo de controis que unha revisión de seguridade empresarial aproba. Con todo, a violación produciuse na capa inferior, na lóxica da aplicación responsable da validación do saldo, a verificación do estado e as comprobacións de idempotencia das capas de almacenamento en caché. Esta capa de software, no caso do ataque informático a Liquid Network, xa asumía que a transacción era válida sen verificala realmente.
Isto revela un defecto crítico na arquitectura moderna de intercambio de criptomoedas que a maioría das túas auditorías de xestión de claves non tocarán:
Todos os modelos importantes de custodia de claves, xa sexan multi-sinatura federada, MPC ou segregación en quente/frío, resolve quen pode autorizar unha retirada, non que se está a autorizar.
Para os creadores de cadeas laterais e plataformas de intercambio de criptomoedas, a conclusión non é "engadir máis asinantes". Un limiar de sinatura (xa sexa 11 de 15 ou 3 de 4 MPC) só garante que se asinaron suficientes entidades autorizadas. Se o software subxacente valida incorrectamente o subministro de tokens ou a lóxica de caché, os asinantes aprobarán fielmente unha transacción baseada nunha mentira.
A conclusión real para aqueles que planean o desenvolvemento dunha plataforma de intercambio de criptomoedas é:
A validación e a lóxica de estado requiren o mesmo illamento adversario e as mesmas suposicións de confianza cero que as claves privadas.
Unha lista de verificación práctica de auditoría para construtores de plataformas de intercambio de criptomoedas e cadeas laterais
Os equipos que constrúen ou operan unha infraestrutura de intercambio de criptomoedas multiactivo , especialmente calquera cousa que se conecte a unha cadea lateral, L2 ou un modelo federado, deben avaliar estas cinco preguntas cruciais xunto coas revisións estándar de custodia de claves:
- Pistas de seguridade independentes: Revísase a lóxica de validación e consenso na súa propia vía de seguridade dedicada, totalmente illada das auditorías de custodia de claves?
- Suposicións de estado non válidas: As suposicións de almacenamento en caché e idempotencia no código da ruta de retirada son sometidas a probas de resistencia explicitamente para escenarios nos que un estado non válido está marcado como xa verificado?
- Interruptores autónomos: Existen límites de taxa de ruta de retirada automatizados ou interruptores automáticos que se activan nun volume anómalo, independentemente dos limiares de sinatura?
- Resposta a incidentes da capa de validación: O seu manual de resposta a incidentes abrangue especificamente un compromiso da capa de validación ou só se prepara para escenarios de compromiso clave?
- Cadencia de revisión sincronizada: A cadencia de revisión do software de execución para a súa lóxica de validación de estado execútase con tanta frecuencia como as auditorías da súa infraestrutura de sinatura?
Que significa isto para as plataformas reguladas e os investidores?
Os auditores e reguladores que avalían a custodia das bolsas hoxe en día fan preguntas detalladas sobre a xestión de claves, centrándose principalmente en:
- proporcións de almacenamento en frío
- limiares de asinante
- Uso de HSM.
Moitos menos solicitan probas de revisión contradictoria sobre a validación e a lóxica de consenso especificamente.
Esa lagoa na auditoría de custodia é exactamente onde se produciu esta vulnerabilidade. A medida que a arquitectura da custodia evoluciona despois de 2026, as empresas fintech reguladas, as plataformas criptonativas e os espazos institucionais deben pechar esta lagoa de forma proactiva, antes de que se converta nun achado de dilixencia debida ou nun seguimento regulatorio posterior ao incidente.
Conclusión
O ataque informático a Liquid Network é un recordatorio de 320 millóns de dólares de que a arquitectura de custodia de intercambio é moito máis grande que a xestión de claves.
En Antier, construímos infraestruturas de custodia e intercambio de criptomoedas con lóxica de validación e consenso tratada como unha superficie de seguridade primaria, non como unha suposición herdada da capa de sinatura. Se estás a construír, actualizar ou auditar unha arquitectura de custodia de intercambio de criptomoedas, ponte en contacto con Antier para unha compilación, integración ou revisión que abarque as tres capas críticas.
Preguntas máis frecuentes
01. A multisinatura de Liquid Network estivo comprometida?
Non. Blockstream confirmou que 11 das 15 claves de sinatura da federación nunca foron comprometidas; a vulnerabilidade era un erro de validación no software Elements.
02. Que é unha peg-out?
Un peg-out é o proceso de retirar activos dunha cadea lateral (como Liquid) de volta á cadea principal de Bitcoin, autorizado polos asinantes da federación e restrinxido a carteiras de destino incluídas na lista branca.
03. En que se diferencia isto dun ataque típico a unha plataforma de intercambio?
A maioría dos ataques informáticos importantes nas plataformas de intercambio inclúen claves privadas comprometidas, phishing ou acceso de persoas con información privilexiada. Esta vulnerabilidade non tocou as claves en absoluto. Aproveitou un fallo de validación de software para facer que os activos falsos parecesen lexítimos para un sistema de custodia que doutro xeito estaría intacto.
04. Que deberían facer agora as plataformas de intercambio que se basean en cadeas laterais federadas?
Tratar a validación e a revisión da lóxica de consenso como unha vía de seguridade distinta e continua da xestión de claves, coa súa propia cadencia de auditoría, probas contradictorias e plan de resposta a incidentes.
