Por qué los puentes no dejan de ser hackeados, y qué es en realidad un token puenteado
Durante buena parte de 2021 y 2022, los puentes entre cadenas fueron lo más fiablemente robado de todo el mundo cripto. No los exchanges, ni los monederos, ni los contratos inteligentes en general: los puentes.
Ronin perdió unos 625 millones de dólares. Poly Network perdió más de 600 millones. Wormhole perdió alrededor de 320 millones. Nomad perdió cerca de 200 millones. Eso son más de mil quinientos millones de dólares en cuatro incidentes, y la lista es más larga que cuatro.
Ninguno de ellos fue un fallo de Bitcoin, de Ethereum ni de ninguna cadena subyacente. Entender por qué es lo más útil que puedes aprender sobre los puentes, porque te dice exactamente en qué estás confiando cuando usas uno.
Las cadenas no pueden hablar entre sí
El problema de raíz es sencillo y se pasa por alto a menudo. Bitcoin no tiene ni idea de que Ethereum existe. Cada cadena valida solo sus propias transacciones y no dispone de mecanismo alguno para observar el estado de otra. No hay forma integrada de que una se entere de lo que ocurrió en la otra.
Así que «enviar BTC a Ethereum» es imposible en sentido literal. Tus bitcoins no pueden abandonar Bitcoin.
Lo que ocurre en realidad es una sustitución. Envías BTC de verdad a una dirección controlada por el puente. El puente lo advierte, y algo en Ethereum te emite un token que representa esos BTC. Cuando quieres salir, quemas el token y el puente libera el original.
La consecuencia crucial: un token puenteado no es el activo. Es un derecho sobre un bote de ese activo, custodiado por quien opere el puente. Su valor descansa por completo en que ese bote siga ahí y en que el operador siga honrando los rescates. Si el bote se vacía, tu token envuelto es un recibo por nada, que es exactamente lo que descubrieron los tenedores en cada uno de los incidentes anteriores.
Alguien tiene que decidir que el depósito ocurrió
Como ninguna cadena puede observar a la otra, algún tercero debe vigilar la cadena A y atestiguar ante la cadena B que hubo un depósito. Ese mecanismo de atestación es el puente, y es por donde se va todo el dinero.
Los diseños varían en cuánta confianza exigen:
Un multifirma o conjunto de validadores: un grupo fijo de firmantes cuyo quórum autoriza las liberaciones. Sencillo, rápido y tan fuerte como el menor número de claves capaz de mover fondos.
Un modelo optimista: los mensajes se dan por válidos salvo que se impugnen dentro de una ventana. Barato, pero depende de que alguien vigile de verdad y de que la lógica de impugnación sea correcta.
Clientes ligeros y pruebas: la cadena de destino verifica pruebas criptográficas del estado de la cadena de origen. El enfoque más sólido y el más caro, razón por la que es menos común de lo que debería.
Todo lo demás son variaciones. Lo que importa es que, en casi todos los casos, entre el bote y un atacante se interponen un pequeño conjunto de partes o una única función de verificación.
Los cuatro fallos, y lo que enseña cada uno
Ronin: claves comprometidas, no código comprometido. El puente usaba un conjunto de nueve validadores que exigía cinco para autorizar una retirada. Un atacante obtuvo cuatro claves mediante phishing dirigido y llegó a la quinta a través de un tercero al que se había concedido acceso de firma tiempo atrás y a quien nunca se le revocó. Cinco de nueve, quórum alcanzado, fondos liberados. No se rompió nada criptográficamente. La comprobación de firmas funcionó a la perfección: sencillamente verificó firmas de un atacante.
La lección no es «el multifirma es malo». Es que un quórum solo significa tanto como la independencia de sus firmantes. Cuatro claves en una misma empresa más un permiso caducado no son un cinco de nueve; se parecen más a un uno de dos disfrazado.
Poly Network: convencieron al contrato de cambiar su propio guardián. El atacante encontró una vía de llamada entre cadenas que le permitió alterar el rol de keeper —lo que decide qué mensajes son legítimos— hacia una dirección bajo su control. A partir de ahí, cada retirada fraudulenta estaba, en lo que al contrato respectaba, debidamente autorizada.
La lección: la función más peligrosa de un puente rara vez es la que mueve dinero. Es la que decide a quién se le permite hacerlo.
Wormhole: la propia comprobación de firmas era defectuosa. Una rutina de verificación podía ser engañada para aceptar un conjunto falsificado de firmas de guardianes, lo que permitió al atacante acuñar 120.000 wETH en Solana que nunca estuvieron respaldados por nada en Ethereum.
La lección: «verificado mediante firmas» no significa nada sin un verificador correcto. La criptografía estaba bien; el código a su alrededor, no.
Nomad: un cambio de configuración abrió la puerta a todo el mundo. Una actualización rutinaria dejó una raíz de confianza fijada en un valor cero, lo que tuvo el efecto de hacer que prácticamente cualquier mensaje pareciera probado. El exploit no requería habilidad especial: la gente copiaba la transacción del primer atacante, cambiaba la dirección por la suya y la repetía. Se convirtió en un vaciado colaborativo.
La lección, y es la incómoda: no fue un ataque exótico. Fue un error de despliegue. La mayoría de las pérdidas en puentes se parecen más a operaciones mal ejecutadas que a criptografía derrotada.
Qué significa esto para ti
Los activos puenteados cargan con el riesgo del puente, no con el de la cadena. Tener BTC envuelto en otra cadena no es tener BTC. Es tener un derecho, garantizado por el componente más débil que resulte tener ese puente. Puede ser perfectamente aceptable, pero debería ser una decisión y no un supuesto.
Prefiere no puentear cuando haya alternativa. Si puedes comprar el activo de forma nativa en la cadena de destino, o usar un exchange centralizado como punto de cruce, has cambiado riesgo de puente por otro riesgo distinto y a menudo mejor comprendido. Ninguna opción está libre de riesgo; simplemente fallan de maneras distintas, y los modos de fallo de los exchanges están al menos bien catalogados.
No dejes valor aparcado en forma puenteada. El riesgo del puente se acumula con el tiempo. Cruzar, hacer aquello a lo que ibas y volver te expone brevemente. Mantener un activo envuelto durante un año te expone un año.
Juzga un puente por su modelo de confianza, no por su interfaz. ¿Cuántos firmantes pueden mover los fondos? ¿Son organizaciones independientes o un solo equipo? ¿Se ha auditado el código y —más revelador aún— ha sobrevivido al tiempo y al volumen? Un frontal reluciente no te dice nada.
Dimensiona la posición según la confianza. La regla sencilla es no puentear más de lo que estarías dispuesto a perder si el operador desapareciera, porque en el peor caso viene a ser lo mismo.
Dónde se sitúa SSP
SSP admite mover activos entre cadenas EVM, y conviene ser exactos sobre qué protege eso y qué no.
Nuestro 2 de 2 protege tus claves y tus aprobaciones. Nadie puede iniciar una transacción de puente sin que ambos dispositivos la firmen, y verás qué estás aprobando en cada uno. Esa propiedad se mantiene por completo.
Lo que no puede hacer es volver seguro el puente en sí. Una vez que tus activos están en el contrato de un puente, se rigen por las reglas de ese contrato y por la gestión de claves de ese operador, no por tu multifirma. La aprobación con dos dispositivos es una protección excelente frente a que alguien mueva tus fondos sin permiso. No es protección alguna frente a que te quiten fondos de un sitio al que los enviaste deliberadamente.
No es una limitación que podamos sortear con ingeniería, y fingir lo contrario sería deshonesto. Los puentes son uno de esos lugares del mundo cripto donde la respuesta honesta es que la seguridad depende casi por entero de otra persona, y la reacción correcta es mirar con atención quién es esa persona antes de cruzar.
