Al bloquear la liquidez para proporcionar enrutamiento a través de la cadena (como hacen ahora casi todos los puentes), los puentes se han colocado en una competición que están destinados a perder.
Tras una serie de explotaciones a gran escala de los puentes, se está dando mucho oxígeno a la narrativa de que la tecnología de cadenas cruzadas es intrínsecamente defectuosa, que la interoperabilidad de las cadenas cruzadas significa riesgo. Con una pérdida estimada de 2.000 millones de dólares en 13 ataques a puentes este año, cada vez es más difícil ignorar este argumento.
En deBridge, creemos que no sólo es imperativo, sino inevitable, que todos los puentes entre cadenas se replanteen por completo su enfoque de la agregación de liquidez.
Las limitaciones de la liquidez bloqueada
Al bloquear la liquidez para proporcionar un enrutamiento a través de la cadena (como hacen casi todos los puentes en la actualidad), los puentes se han colocado en una competición que están destinados a perder. Estamos viendo cómo los puentes se enfrentan a protocolos de liquidez establecidos y creados a propósito, como AAVE, Compound y Frax, proyectos que sin duda monetizarán la liquidez de forma más eficaz y segura. Abundan los ejemplos de puentes con cientos de millones de dólares en TVL, con una utilización extremadamente baja de la liquidez bloqueada.
Con este diseño, los proyectos puente se ven obligados a realizar campañas insostenibles de extracción de liquidez que no ofrecen soluciones de eficiencia de capital a largo plazo. A menos que los incentivos de los tokens se mantengan indefinidamente -una ambición poco sólida para cualquier proyecto-, los proveedores de liquidez retirarán inevitablemente el capital para buscar oportunidades de mayor rendimiento.
Para agregar liquidez de forma segura, los puentes tendrían que adquirir pólizas de seguro para que los proveedores de liquidez tuvieran la capacidad de cubrir los riesgos. Este es otro gasto que dificulta aún más la monetización de la liquidez. Por eso, la mayoría de los puentes existentes no son rentables, ya que los costes y las recompensas de la minería de liquidez pagada suelen superar el beneficio neto del protocolo.
También hay consideraciones arquitectónicas en juego, dado que una transferencia de valor a través de la cadena es una solicitud que puede liquidarse de diferentes maneras. Todos los puentes existentes liquidan estas órdenes desde sus propios pools de liquidez, donde la liquidez se bloquea continuamente cuando se necesita sólo en el momento preciso en que la transferencia de valor debe cumplirse.
El tamaño de la orden también puede diferir: si supera el tamaño de la reserva de liquidez del puente, el remitente acabará con tokens envueltos o con una transacción suspendida/atrapada indefinidamente. Por otro lado, si la orden es demasiado pequeña para el tamaño del pool de liquidez, la utilización de la liquidez es muy baja e ineficiente. Este círculo vicioso pone aún más de relieve que este enfoque del protocolo de liquidez para el diseño de puentes es ineficaz y fundamentalmente erróneo.
Solución del problema de seguridad
Por muy importante que sea este tema, la insostenibilidad económica no es el único reto principal. Incluso suponiendo que los puentes hayan descubierto una forma de utilizar el enfoque de liquidez bloqueada y seguir siendo eficientes en términos de capital, a estas alturas es evidente que construir un protocolo de liquidez seguro es una tarea que lo consume todo. De hecho, al convertirse, a sabiendas o no, en protocolos de liquidez, los proyectos de puentes se están dando a sí mismos la inmensa tarea de salvaguardar una superficie de ataque multifacética.
Para empezar, uno de los problemas evidentes de un puente de liquidez bloqueado es que crea un efecto multiplicador del riesgo, en el que las vulnerabilidades de una cadena apoyada pueden extenderse para comprometer el capital mantenido en otros ecosistemas.
En este caso, está la cuestión de la seguridad por delegación. Un puente puede ver comprometida toda su base de liquidez si existe una posible vulnerabilidad en la base de código de una cadena de bloques/L2 compatible. Vimos esta posibilidad a principios de este año con una vulnerabilidad descubierta en Optimism, que habría permitido a los atacantes acuñar una cantidad arbitraria de activos y, previsiblemente, intercambiarlos por tokens en otros ecosistemas.
La semana pasada, descubrí (y reporté) un error crítico (que ha sido totalmente parcheado) en @optimismPBC (una «solución de escalamiento de capa 2» para Ethereum) que habría permitido a un atacante imprimir una cantidad arbitraria de tokens, por lo que gané una recompensa de 2.000.042 dólares. https://t.co/J6KOlU8aSW
– Jay Freeman (saurik) (@saurik) 10 de febrero de 2022
De nuevo, cualquier problema con el mecanismo de consenso de una cadena también puede provocar un contagio sistémico, poniendo en riesgo cualquier liquidez bloqueada en otras cadenas apoyadas. En este caso, el puente simplemente difunde el problema a otras cadenas. Esto podría incluir ataques del 51% u otros fallos a nivel de protocolo.
Aparte de este tipo de riesgos heredados, cada vez vemos más situaciones en las que los errores cometidos por los propios proyectos de puentes han provocado, de un modo u otro, una pérdida de liquidez bloqueada. Desde actualizaciones chapuceras del protocolo, un mal diseño de los contratos inteligentes o una infraestructura comprometida de los validadores, hay muchos escenarios en los que los malos actores pueden explotar las vulnerabilidades del propio puente.
Todos estos riesgos se agravan rápidamente y -como hemos visto en demasiadas ocasiones- acaban siendo asumidos por los proveedores de liquidez cuando pierden la posibilidad de canjear sus activos envueltos. Esta posibilidad debería ser inaceptable.
Pocos niegan la gran promesa de la interoperabilidad entre cadenas para impulsar la adopción de Web3 a nuevas cotas. Sin embargo, la magnitud y la frecuencia de los ataques a los puentes han puesto de manifiesto la necesidad de replantear el diseño fundamental de la tecnología de los puentes a partir de los principios básicos. El diseño de puente convertido en protocolo de liquidez simplemente no está funcionando.
¿Existe alguna forma de concebir un enfoque fundamentalmente nuevo y único para el diseño de puentes, que elimine completamente los riesgos para los proveedores de liquidez, elimine los vectores de ataque y, al mismo tiempo, preserve el máximo nivel de eficiencia del capital?
Es posible que haya exactamente eso en un futuro próximo. En deBridge, estamos trabajando en un nuevo enrutamiento de liquidez a través de la cadena que resuelve todos estos problemas. Esté atento.
