Seguridad de puentes cross-chain: ¿realmente necesitas uno?

Los sistemas cross-chain permiten que una blockchain actúe a partir de información sobre otra. Esto añade supuestos de verificación, custodia, liquidez y operación. Algunos diseños introducen validadores externos; otros verifican pruebas de la cadena de origen o utilizan liquidez local. La pregunta adecuada no es solo si un puente ha sido auditado. Es qué supuestos pueden mover valor, cómo se contiene un fallo y si el producto necesita movimiento cross-chain.

La guía actual de ethereum.org sobre puentes distingue enfoques verificados externamente, verificados de forma local o nativa, optimistas, basados en clientes ligeros y redes de liquidez. También subraya que ningún diseño es perfecto: seguridad, conectividad, latencia, capacidades y coste implican compromisos.

¿Cómo puede perder fondos un puente cross-chain?

Un puente de activos suele bloquear, quemar, liberar o intercambiar valor tras aceptar evidencia de un evento en otra cadena. Esa evidencia puede proceder de firmantes externos, una red de oráculos, un cliente ligero, un proceso de pruebas de fraude o transacciones en las cadenas conectadas. Por tanto, la superficie de ataque depende del diseño.

• Compromiso de claves y gobernanza. Un atacante alcanza el umbral capaz de autorizar mensajes, actualizaciones o retiros.
• Fallo de verificación o contrato. El código on-chain acepta un mensaje, una prueba o una transición de estado falsificados, repetidos o inválidos.
• Fallo económico o de liquidez. Una transferencia verificada localmente o una red de liquidez aún puede sufrir riesgos de pool, precios, inventario, relayers o liquidación.
• Fallo operativo. La monitorización, los permisos, las actualizaciones, la respuesta, los frontends o las dependencias fallan aunque la lógica prevista sea correcta.

No todos los puentes guardan todo el valor de los usuarios en un contrato y no todos los fallos tienen un radio de impacto ilimitado. Revisa contratos, límites, garantías, liquidez por ruta, controles de actualización y vías de recuperación reales, en vez de confiar en la etiqueta «puente».

¿Qué demostraron realmente Ronin, Wormhole y Nomad?

Ronin, marzo de 2022. Ronin informó del drenaje de 173.600 ETH y 25,5 millones de USDC. Su actualización de seguridad describió la brecha como un recordatorio de la importancia de las redes distribuidas y propuso más validadores independientes y límites de retiro. El anuncio oficial de reapertura documenta reembolsos, auditorías, cambios de gobernanza, niveles de retiro, revisión humana para los retiros mayores, un disyuntor y un límite diario. La independencia de validadores, el ciclo de vida de permisos, la política de retiros y la detección forman parte del perímetro de seguridad. El número de validadores o firmas no demuestra por sí solo la independencia de las claves.

Wormhole, febrero de 2022. Su informe del incidente indica que un atacante explotó el contrato de Solana y acuñó 120.000 ETH envueltos por Wormhole sin garantía. La vulnerabilidad estaba en la verificación del contexto de la instrucción, no era evidencia de que el quorum de guardianes firmara el mensaje fraudulento. Hay que verificar la prueba completa y su contexto de ejecución, no solo un objeto relacionado con firmas.

Nomad, agosto de 2022. Su análisis de causa raíz afirma que un error en Replica permitió que mensajes no probados superaran la autenticación tras una actualización de junio de 2022. Una raíz cero inicializada y la comprobación modificada hicieron que acceptableRoot(bytes32(0)) devolviera verdadero. Sus watchers vigilaban el compromiso de la clave del updater, no comportamientos causados por un error del contrato, por lo que el incidente no los activó. Hay que modelar actualizaciones y monitorización frente a varias clases de fallo.

Las estimaciones históricas en dólares dependen del precio de los tokens y del momento elegido. Por eso usamos las cantidades comunicadas por los proyectos cuando están disponibles. Los tres incidentes ejemplifican fallos distintos, no demuestran una causa universal.

¿Necesitas un puente?

Empieza por el resultado para el usuario y las garantías de liquidación necesarias.

• ¿Puede el producto permanecer en una cadena? Si usuarios, activos y contrapartes ya comparten un dominio, cross-chain puede añadir riesgo sin suficiente valor.
• ¿Existe una ruta consolidada? Para una L2, examina su puente designado y los riesgos actuales, incluida la madurez de pruebas, claves de actualización, pausas, retrasos y disponibilidad de datos. «Canónico» no significa libre de riesgo ni inmutable.
• ¿Necesitas activos, mensajes o solo datos? La custodia lock-and-mint, la ejecución de mensajes, la liquidación de intents y la lectura de estado tienen requisitos distintos.
• ¿Puede el producto ofrecer opciones en vez de custodia? Un agregador o enlaces a terceros pueden reducir el desarrollo propio, pero añaden supuestos de routing, frontend, allowances y terceros que deben comunicarse y monitorizarse.

Construye un puente propio solo cuando las rutas existentes no satisfagan un requisito documentado y el equipo pueda financiar seguridad, revisión independiente, monitorización, actualizaciones y respuesta durante toda la vida del sistema.

¿Cómo deberías comparar los modelos de confianza?

Las etiquetas son solo un punto de partida. Las implementaciones suelen combinar modelos, y los controles administrativos o de actualización pueden dominar el método anunciado.

Los clientes ligeros pueden reducir la dependencia de firmantes externos, pero no son automáticamente la opción más segura en todos los despliegues. Siguen importando errores, finalidad, gobernanza, actualizaciones y cadenas conectadas. Compara el sistema implementado y sus controles, no una etiqueta. Nuestra nota sobre costes de gas en L1 y L2 cubre una parte de la decisión.

¿Qué debe incluir una revisión previa al lanzamiento?

1. Documenta activos, mensajes y autoridad. Identifica contratos, firmantes, gobernadores, actualizadores, pausadores, relayers, oráculos y dependencias.
2. Expón los supuestos de seguridad y disponibilidad. Define umbral, finalidad, disputa, datos, liquidez y censura por ruta.
3. Prueba ambos lados y su unión. Revisa contratos, agentes, serialización, protección contra repetición, separación de dominios, pruebas y recuperación.
4. Refuerza claves y permisos. Usa custodia independiente cuando proceda, mínimo privilegio, rotación, revocación y recuperación probada.
5. Limita el impacto. Evalúa topes, límites de tasa, retrasos, disyuntores, despliegues graduales y garantías, con sus compromisos.
6. Monitoriza invariantes. Reconcilia suministro, escrow, mensajes, firmas, liquidez y retiros. Las alertas necesitan responsables y respuestas ensayadas.
7. Trata las actualizaciones como eventos de seguridad. Verifica almacenamiento e inicialización, repite pruebas y revisión, despliega por etapas y ensaya reversión o pausa.
8. Prepara respuesta y comunicación. Decide quién pausa, cómo conservar pruebas, desactivar rutas e informar a los usuarios.

"La revisión de un puente empieza por la autoridad y la contención del fallo: ¿quién puede hacer que el destino actúe y qué limita el daño cuando un supuesto deja de cumplirse?"

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

No existe una opción universal. Un puente L2 designado puede minimizar supuestos adicionales para su ruta, pero aún puede incluir gobernanza de actualizaciones, pausas, pruebas inmaduras, retrasos u otras restricciones. Un tercero puede ofrecer rutas más rápidas o amplias e introducir validadores, solvers, liquidez u otros contratos. Compara documentación actual por ruta y comunica los supuestos.

Q&A: ¿basta un multisig?

Puede ser un control, pero su umbral no demuestra independencia, custodia, monitorización ni contención. Revisa quién controla cada clave, si una organización alcanza el quorum, cómo caducan permisos y qué límites, retrasos, pausas y alertas rodean una firma válida.

Q&A: ¿garantizan la seguridad las auditorías?

No. Aportan evidencia sobre un alcance, versión, entorno y momento definidos. No garantizan futuras actualizaciones, claves, gobernanza, cadenas, liquidez u operaciones. Nomad indica que el cambio relevante estuvo incluido durante la auditoría y se desplegó después. Importan las versiones exactas, la verificación de correcciones, el despliegue y la monitorización continua. Consulta nuestra checklist previa a la auditoría.

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

Normalmente, solo si la verificación o liquidación cross-chain es su producto diferencial y las rutas existentes no cumplen un requisito documentado. De lo contrario, permanecer en una cadena o integrar una ruta revisada evita una obligación continua. Si hace falta uno propio, presupuéstalo como infraestructura crítica con responsables durante todo su ciclo de vida. Consulta nuestro servicio de ingeniería blockchain y el glosario.