Los puentes entre cadenas han perdido más valor por ataques que cualquier otra categoría de infraestructura cripto, y no es porque quienes los construyen sean descuidados. Es por lo que un puente es fundamentalmente, y una vez claro eso el patrón de fallos deja de parecer mala suerte.
El modelo mental que casi todos llevan es el de un activo que viaja de una cadena a otra, como un archivo pasa de un ordenador a otro. Nada de eso ocurre, y no puede: una blockchain es un sistema cerrado que solo conoce su propio estado, y no tiene mecanismo alguno para observar qué es verdad en otra cadena. No hay cable entre ellas ni realidad común a la que apelar.
Lo que ocurre realmente es que el activo se inmoviliza en la primera cadena y se crea uno nuevo en la segunda, que representa un derecho sobre el original inmovilizado. Las dos mitades no están unidas por nada salvo por un sistema que decide cuándo crear el derecho, y esa decisión es toda la cuestión de seguridad. Todo lo que hace un puente se reduce a responderla: quién puede decir que se bloquearon activos al otro lado, y qué le impide decirlo en falso.
Un puente no mueve valor. Bloquea valor en un sitio y emite una promesa en otro, y todos los grandes fallos han sido ataques contra la promesa y no contra el cerrojo.
El token que recibes no es el activo que depositaste. Es un instrumento distinto, emitido por el puente, cuyo valor depende enteramente de que el activo depositado siga bloqueado y recuperable. Si el cerrojo se ve comprometido o el mecanismo de emisión se explota, el token sigue existiendo y negociándose mientras lo que lo respalda ya no, que es exactamente la secuencia observada en los mayores incidentes.
Esto tiene una consecuencia que pilla a la gente incluso después de entender el mecanismo. Tener un activo puenteado es tener un derecho sobre un puente concreto, no sobre el subyacente. Dos versiones del mismo activo en la misma cadena, llegadas por puentes distintos, son instrumentos distintos con riesgos distintos y a menudo precios distintos, y se muestran con frecuencia con el mismo nombre y el mismo logo.
La forma práctica de eso es saber qué puente emitió lo que tienes antes de tenerlo, y comprobar que el activo que recibes es el que el ecosistema en el que entras usa de verdad. Cobrar en una versión puenteada que nadie acepta es un problema de liquidez encima de uno de custodia.
Las diferencias que importan no van de velocidad ni de comisiones. Van de quién es capaz de autorizar la emisión de un derecho, y de cuántos de ellos tendrían que equivocarse o mentir a la vez.
Un conjunto definido de partes observa el depósito y firma la emisión, normalmente con un requisito de umbral. Es el diseño más común y el más fácil de construir, y su seguridad es exactamente la de ese conjunto: si el número umbral de claves de firma se ve comprometido, el atacante puede emitir derechos respaldados por nada. Varias de las mayores pérdidas del sector siguieron precisamente ese camino, y el número de claves exigido fue en todos los casos lo bastante pequeño como para reunirse.
Un diseño de cliente ligero coloca suficiente lógica de consenso de una cadena en un contrato de la otra como para que pueda verificar pruebas directamente, sin comité implicado. Es el modelo más sólido disponible, porque el supuesto de confianza se reduce a la seguridad de las dos cadenas mismas. También es difícil y caro de construir, y por eso existen bastantes menos de los que el paisaje comercial sugiere.
En lugar de bloquear y emitir, algunos sistemas mantienen fondos del mismo activo en ambas cadenas y simplemente pagan desde el fondo de destino cuando llega un depósito al origen. No se crea nada nuevo, lo que elimina por completo el ataque por emisión, y el riesgo se desplaza a si los fondos se mantienen equilibrados y a quién los aporta. Es una forma de riesgo genuinamente distinta y no un riesgo menor.
Un puente guarda la totalidad de los activos bloqueados de todos los usuarios que lo han cruzado, en un solo sitio, en un contrato que debe seguir siendo capaz de liberarlos. Eso lo convierte en el mayor fondo de valor individual de casi todos los ecosistemas, custodiado por código más nuevo y menos escrutado que las cadenas a ambos lados, y encargado del trabajo más complejo de toda la pila.
Añade que ese trabajo es intrínsecamente adverso de un modo que los contratos de negociación no lo son. Un puente debe decidir si ocurrió un suceso en un sistema que no puede ver, a partir de pruebas suministradas por partes que pueden beneficiarse de mentir sobre ello. Es un problema más duro que transferir un token, tiene más sitios donde equivocarse, y equivocarse una vez es ilimitado en vez de incremental.
El resultado no sorprende una vez enunciado: el valor más alto, el código más nuevo, el problema más duro, y una población de atacantes que solo necesita encontrar un defecto. El patrón de pérdidas de esta categoría es lo que esa combinación produce, y nada en él es propio de un equipo concreto.
Agrupar los incidentes en vez de enumerarlos revela un puñado de mecanismos repetidos.
El conjunto umbral de claves que autoriza la emisión se vio comprometido, a menudo por medios ordinarios y no criptográficos: una máquina de desarrollador, una credencial robada, un ataque de ingeniería social sobre una persona. El puente emitió entonces derechos que ningún depósito respaldaba, y se vendieron al mercado antes de que nadie lo notara.
Un defecto en la lógica de verificación dejó pasar como válido un mensaje falsificado o reproducido. Son los fallos de software más puros de la categoría, son sutiles, y varios de ellos sobrevivieron a auditorías, porque verificar una prueba correctamente es difícil de acertar y difícil de revisar.
Un contrato cuya función de instalación podía volver a invocarse, o cuyo rol privilegiado nunca se renunció, permitió a un atacante tomar el control del mecanismo sin más. Es un error de despliegue y no de diseño, y ha causado pérdidas muy grandes.
Los puentes son con frecuencia actualizables, lo que es sensato dada la juventud del código, y un contrato actualizable tiene una autoridad capaz de reemplazar su lógica. Comprometer esa autoridad equivale a comprometer todo lo que el contrato guarda, sin necesidad de encontrar defecto alguno en el código actual.
Tres de los cuatro modos de fallo van de quién tiene la autoridad y no del código. Los ataques que funcionaron normalmente no necesitaron romper el mecanismo, solo convertirse en la persona autorizada a manejarlo.
Casi todas las cadenas designan un puente como canónico, es decir construido y operado por el mismo equipo que la cadena, y los activos que emite son los que el ecosistema trata como nativos. Esa designación merece atención porque concentra liquidez: la versión canónica de un activo es la que se negocia en todas partes de esa cadena, y cualquier otra versión es un instrumento distinto con mercados más delgados.
No es automáticamente más segura, y tratarla como una nota de seguridad es un error. Un puente canónico hereda las mismas tres opciones de diseño que cualquier otro y puede ser igualmente un comité con claves. Lo que sí aporta es la respuesta a otra pregunta, la de si el activo que recibes será aceptado donde piensas usarlo, y esa pregunta merece resolverse aparte de la de seguridad.
Una parte sustancial del puenteo se hace por razones que no exigen un puente, y notarlo es la reducción de riesgo más barata disponible. Si ambas cadenas están soportadas por una plataforma que ya usas, depositar en una y retirar en la otra logra el mismo resultado pasando por una entidad que ya habías aceptado como contraparte, lo que es un riesgo que ya llevabas y no uno nuevo.
Donde el activo existe de forma nativa en ambas cadenas porque su emisor lo despliega en las dos, tampoco hace falta puente: el emisor puede destruir de un lado y emitir del otro, y varios activos importantes funcionan así. Comprobar si esa ruta existe antes de usar un puente lleva un minuto y elimina toda la categoría de riesgo descrita arriba.
El caso restante, donde un puente es realmente el único camino, es más estrecho de lo que el volumen que los atraviesa sugiere. Buena parte de ese volumen es costumbre y no necesidad, y la costumbre es cara de una forma que solo aparece los días en que lo es.
Cuatro preguntas, ninguna de las cuales exige leer código. De qué diseño se trata, es decir si la emisión la autoriza un comité, una prueba que la cadena verifica, o nadie porque hay liquidez a ambos lados. Si es un comité, cuántas firmas se exigen y si esas partes son identificables e independientes. Es actualizable el contrato, y si lo es quién controla la actualización y si ese control está a su vez repartido. Y existe una ruta sin puente al mismo destino.
Después el hábito operativo que no cuesta nada: cruza el importe que necesitas y no el que tienes, y no dejes valor en forma puenteada más tiempo del que la razón para puentear exige. El tiempo expuesto es la variable más bajo tu control, y buena parte del valor perdido en esta categoría estaba parado o en tránsito y no en uso activo en el momento en que desapareció.
No. Se bloquea en la cadena de origen y se crea un token nuevo que representa un derecho sobre él en la cadena de destino. Nada cruza, porque una blockchain no puede observar el estado de otra. Toda la seguridad de un puente va de quién puede autorizar ese segundo paso.
Guardan el mayor fondo de valor individual de casi todos los ecosistemas, su código es más nuevo y menos escrutado que las cadenas de alrededor, y realizan la tarea más dura de la pila: decidir si algo ocurrió en un sistema que no pueden ver. Un atacante solo necesita encontrar un defecto, y la recompensa es ilimitada.
Con frecuencia no. Si llegaron por puentes distintos son instrumentos distintos con respaldo distinto, riesgos distintos y a menudo precios distintos, pese a compartir normalmente nombre y logo. Saber qué puente emitió lo que tienes forma parte de saber qué tienes.
Es el puente designado por el propio equipo de la cadena, y los activos que emite son los que el ecosistema trata como nativos. Eso responde a una pregunta de liquidez y no de seguridad: te dice que el activo será aceptado donde quieras usarlo. Su seguridad sigue dependiendo de las mismas opciones de diseño que cualquier otro puente.
Aquel en que la cadena de destino verifica directamente pruebas de la cadena de origen, porque el supuesto de confianza se reduce a la seguridad de las dos cadenas mismas y no a un comité. También es el más difícil y caro de construir, y por eso existen bastantes menos de los que el vocabulario sugiere.
A menudo. Si una plataforma que ya usas soporta ambas cadenas, depositar en una y retirar en la otra llega al mismo destino a través de una contraparte que ya habías aceptado. Y donde un emisor despliega el mismo activo de forma nativa en ambas cadenas, no interviene puente alguno. Comprobar cualquiera de las dos rutas lleva un minuto.
Reduce la probabilidad de ciertas clases de defecto y no ha impedido varios de los mayores incidentes. La lógica de verificación es lo bastante sutil como para que errores hayan sobrevivido a la revisión, y tres de los cuatro modos de fallo habituales van de quién tiene la autoridad y no del código que una auditoría examina.
Tan poco como la razón para puentear exija. El tiempo expuesto es la variable más bajo tu control, y buena parte del valor perdido en esta categoría estaba parado o en tránsito y no en uso activo en el momento en que el mecanismo falló.