Por qué los puentes cross-chain siguen siendo vaciados (y si realmente necesitas uno)

Los puentes cross-chain son el objetivo más lucrativo en cripto. Solo en 2022, los exploits de puentes vaciaron aproximadamente 2.000 millones de dólares, alrededor del 69% de todos los fondos robados a DeFi ese año, y el total acumulado en los incidentes de puentes reportados ya está muy por encima de 2.500 millones de dólares. El resumen honesto: los puentes se vacían por sus supuestos de confianza, no solo por código malo. Un puente tiene que convencer a una cadena de que algo pasó en otra cadena que no puede ver. Lo que sea que designes para hacer esa afirmación, validadores, un multisig, un comité de firmantes, es justo lo que un atacante va a atacar. Este post empieza por la decisión que la mayoría de los equipos se saltan: ¿necesitas siquiera un puente, y qué modelo de confianza falla y cómo?

¿Cómo se vacían realmente los puentes cross-chain?

Un puente hace una cosa difícil: hace que la cadena B crea que un depósito ocurrió en la cadena A. La cadena B no tiene una forma nativa de verificar la cadena A, así que el puente inserta una autoridad que lo atestigua. Esa autoridad es la superficie de ataque. Vaciar un puente casi siempre es hacer una de tres cosas: robas las claves que autorizan los retiros, engañas a la lógica de verificación para que acepte un mensaje que nunca fue válido, o explotas la economía de un pool de liquidez que adelanta los fondos. Las cantidades son enormes porque un puente concentra el valor bloqueado de todo lo que alguna vez lo cruzó en un solo contrato. No hay radio de impacto por usuario. Hay un único honeypot.

Este encuadre importa porque te dice dónde mirar. El código del smart contract puede ser impecable y el puente seguir siendo vaciado si los firmantes off-chain están comprometidos (Ronin). Los firmantes pueden ser honestos y el puente seguir siendo vaciado si la verificación on-chain tiene un agujero (Wormhole, Nomad). Estás asegurando dos sistemas, no uno, y la mayoría de los post-mortems se remontan al modelo de confianza que el equipo eligió al principio.

Tres fallos diseccionados: Ronin, Wormhole, Nomad, qué enseña cada uno

Ronin (~625M $, marzo de 2022). El mayor hack de puente hasta la fecha. Ronin usaba nueve validadores y requería cinco firmas para aprobar un retiro. El atacante obtuvo cinco claves: cuatro las controlaba Sky Mavis, y una quinta vino de un validador de Axie DAO cuyo acceso se había concedido antes y nunca se revocó. Con cinco de nueve, los retiros eran perfectamente válidos según las propias reglas del puente. El código hizo exactamente lo que se le ordenó. Lección: un conjunto de validadores externos es solo tan seguro como su gestión de claves y su umbral de honestidad. Cinco firmantes no son descentralización; son un único punto de fallo de cinco personas. La brecha pasó desapercibida durante seis días porque nadie vigilaba el conjunto de firmantes.

Wormhole (~325M $, febrero de 2022). Un fallo puro de verificación. Wormhole dependía de un conjunto de "guardians" off-chain cuyas firmas autorizan el minting en la cadena de destino. El contrato del lado de Solana usaba una instrucción obsoleta para comprobar que las firmas se habían verificado, pero nunca validó que el programa de verificación de firmas fuera el real. El atacante proporcionó una cuenta falsificada, pasó la comprobación en un contexto distinto, y minteó 120.000 wETH sin nada que lo respaldara. Lección: los firmantes eran honestos; el código on-chain que confiaba en ellos no fue cuidadoso. Un esquema de firma es solo tan bueno como el contrato que lo comprueba.

Nomad (~190M $, agosto de 2022). Un puente optimista cuya verificación quedó efectivamente apagada por una actualización rutinaria. El contrato Replica de Nomad inicializó su trusted root a 0x00, el mismo valor que lleva un mensaje no probado, de modo que todo mensaje con prueba vacía se trataba como ya probado. Un usuario envió 0,01 WBTC y sacó 100. El exploit no requería habilidad: la gente copiaba la transacción que funcionaba, cambiaba su propia dirección y la reenviaba. Se convirtió en un festín colectivo y crowdsourced con cientos de wallets vaciando el puente en horas. Lección: los diseños optimistas y con fraud proofs ponen todo el modelo de seguridad en una sola comprobación de verificación. Rompe esa comprobación y no hay plan B.

La pregunta de verdad: ¿necesitas siquiera un puente?

La mayoría de los equipos recurren a un puente antes de preguntarse si deberían. El puente más barato de asegurar es el que nunca construyes. Antes de aceptar la responsabilidad, hazte tres preguntas:

• ¿Puedes quedarte en una sola cadena? Si tus usuarios y tu liquidez viven en una cadena, un puente añade una superficie de ataque para un problema que no tienes. Elige la cadena correcta y quédate ahí.
• ¿Puedes usar un puente canónico / nativo? La mayoría de las L2 lanzan un puente oficial mantenido por el equipo de la cadena, asegurado por el propio sistema de pruebas de la cadena. Es más lento y menos flexible que un puente de terceros, pero heredas la seguridad de la cadena en lugar de avalar la tuya propia. Es el default correcto para casi cualquiera que mueva activos hacia y desde una L2.
• ¿Realmente necesitas mover activos, o solo mensajes? Muchos requisitos de "necesitamos un puente" son en realidad "necesitamos leer estado de otra cadena". Eso es un problema más pequeño y barato que bloquear y mintear valor.

Construye un puente personalizado solo cuando tengas una razón específica que las opciones canónicas y de terceros establecidas no puedan cubrir, y solo con los ojos abiertos al coste de auditoría y operación. Un puente no es una funcionalidad que lanzas y olvidas. Es un contrato que guarda el dinero de todos, vigilado por todos los que tienen un incentivo para romperlo.

Modelos de confianza de puentes y cómo falla cada uno

Cada puente elige un modelo de confianza. El modelo decide en quién confías y por tanto cómo te vacían. Esta es la comparativa que hay que tener antes de escribir una línea de código.

La verificación nativa / light-client es la más segura porque elimina por completo el conjunto de confianza humano: la cadena de destino comprueba ella misma la prueba de consenso de la cadena origen. También es la más cara de construir y operar, que es justo por lo que los equipos se convencen de usar un multisig y acaban en esta lista. El fallo de Wormhole estaba en el hueco entre un modelo de firmantes y el contrato que lo verificaba; ve nuestra nota sobre los trade-offs de coste de gas entre L1 y L2 sobre por qué la opción barata rara vez es barata al final.

Una checklist de seguridad de puente previa al lanzamiento

Corta, orientada a la decisión y ordenada por lo que realmente te salva. Si no puedes responder las tres primeras, no estás listo para lanzar.

1. Nombra tu modelo de confianza en voz alta. Escribe exactamente quién puede autorizar un retiro y qué hace falta para comprometerlo. Si la respuesta es "cinco claves", trátalo como un único punto de fallo de cinco personas.
2. Audita ambas capas juntas. La verificación on-chain y los firmantes off-chain son un solo sistema. Wormhole y Nomad fueron bugs on-chain; Ronin fue off-chain. Audita la costura, no solo los contratos.
3. Revoca de forma agresiva. Ronin cayó en parte por un permiso obsoleto que nadie quitó. Inventaría cada clave y concesión, y haz que el acceso caduque por defecto.
4. Monitoriza el conjunto de firmantes y los balances en tiempo real. Ronin estuvo seis días sin que nadie lo notara. Necesitas alertas en cada retiro y cada cambio de firmante, con una persona de guardia.
5. Construye una pausa / circuit breaker. Un límite de tasa o una pausa global convierte un vaciado total en un incidente contenido. Nomad no tenía freno una vez que la primera transacción funcionó.
6. Pon topes y límites de tasa a los retiros. El honeypot es el problema. Los topes encogen el premio y te compran tiempo para reaccionar.
7. Planifica la ruta de actualización. El bug de Nomad llegó en una actualización rutinaria. Trata cada actualización del puente como una auditoría nueva, no como un parche.

"Un puente es un contrato que guarda el dinero de todos, vigilado por todos los que tienen una razón para romperlo. El puente más barato de asegurar es el que nunca construyes."

Q&A: ¿puente canónico o puente de terceros?

Por defecto, el puente canónico cuando mueves activos hacia y desde una L2. Heredas la propia seguridad y el sistema de pruebas de la cadena en lugar de avalar un conjunto de confianza separado. Los puentes de terceros ganan en velocidad, en cadenas que un puente canónico no conecta y en funciones de UX que al puente oficial le faltan, pero ahora estás confiando en el modelo de ese operador además de en tus propias cadenas. Elige un puente de terceros por lo que aporta de forma única, no porque fue el primer resultado.

Q&A: ¿basta un multisig para asegurar un puente?

Un multisig es un punto de partida, no un modelo de seguridad. Ronin era un multisig: cinco de nueve, y perdió 625M $ porque cinco claves eran alcanzables. Un multisig solo ayuda si las claves son genuinamente independientes, en manos de partes que no pueden coludir, con custodia por hardware y disciplina de revocación. En el momento en que una entidad controla un quórum, el multisig es teatro. Si tu puente guarda valor relevante, un multisig debería ser una capa con topes, monitorización y una pausa detrás, no toda la defensa.

Q&A: ¿garantizan las auditorías que un puente es seguro?

No. Una auditoría reduce la probabilidad de un bug de código; no cambia tu modelo de confianza. El valor fatal de Nomad se introdujo después de las auditorías, en una actualización. Wormhole estaba auditado. Una auditoría es una instantánea de una versión de una capa. No puede certificar que tus cinco firmantes seguirán siendo honestos ni que tu próxima actualización no reintroducirá un agujero. Trata las auditorías como necesarias e insuficientes. Ve nuestra checklist de seguridad previa a la auditoría sobre qué hacer antes y después de una.

Q&A: ¿debería una startup construir su propio puente?

Casi nunca. Los equipos en la tabla de pérdidas no eran aficionados descuidados; eran equipos financiados con auditorías e ingenieros. Un puente concentra un riesgo que escala con todo lo que lo cruza, y exige monitorización 24/7 y un plan de respuesta a incidentes desde el día uno. Si eres una startup, quédate en una sola cadena o usa un puente canónico hasta que un puente sea genuinamente tu producto y no una funcionalidad. Cuando sea inevitable, dimensiónalo como lo de mayor riesgo que vas a lanzar y dótalo de recursos en consecuencia. Ve nuestro servicio de ingeniería blockchain sobre cómo lo dimensionamos, y el glosario para los términos anteriores.