Artículo de opinión: Reimaginando los puentes entre cadenas: dejemos de intentar ser protocolos de liquidez Inteligencia de datos PlatoBlockchain. Búsqueda vertical. Ai.

Artículo de opinión: Reimaginar los puentes entre cadenas: dejemos de intentar ser protocolos de liquidez

Después de una serie de hazañas de puentes a gran escala, se está dando mucho oxígeno a la narrativa de que la tecnología de cadena cruzada es inherentemente defectuosa, que la interoperabilidad de cadena cruzada significa riesgo. Con una pérdida estimada de $ 2 mil millones en 13 ataques a puentes este año, se está volviendo cada vez más difícil ignorar este argumento.

At DeBridge, creemos que no solo es imperativo sino inevitable que todos los puentes entre cadenas reconsideren por completo su enfoque de la agregación de liquidez.

Las limitaciones de la liquidez bloqueada

Al bloquear la liquidez para proporcionar enrutamiento de cadena cruzada (como casi todos los puentes lo hacen en este momento), los puentes se han colocado en una competencia que seguramente perderán. Estamos viendo puentes que se enfrentan a protocolos de liquidez establecidos y especialmente diseñados como AAVE, Compuestoy 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 liquidez bloqueada.

Con este diseño, los proyectos puente se ven obligados a ejecutar campañas de minería de liquidez insostenibles que no ofrecen soluciones de eficiencia de capital a largo plazo. A menos que los incentivos simbólicos se mantengan indefinidamente, una ambición poco sólida para cualquier proyecto, los proveedores de liquidez inevitablemente retirarán capital para buscar oportunidades de mayor rendimiento.

Para agregar liquidez de manera segura, los puentes necesitarían adquirir pólizas de seguro para permitir que los proveedores de liquidez tengan la capacidad de cubrir los riesgos. Este es otro gasto que dificulta aún más la monetización de la liquidez. Es por eso que la mayoría de los puentes existentes no son rentables, ya que los costos y las recompensas de minería de liquidez pagadas a menudo superan la ganancia neta del protocolo.

También hay consideraciones arquitectónicas en juego aquí, dado que una transferencia de valor entre cadenas es una solicitud que se puede resolver de diferentes maneras. Todos los puentes existentes liquidan estas órdenes desde sus propios fondos de liquidez donde la liquidez se bloquea continuamente cuando se necesita solo en el momento preciso en que se debe realizar la transferencia de valor.

El tamaño de la orden también puede diferir: si excede el tamaño del grupo de liquidez del puente, el remitente terminará con tokens envueltos o una transacción suspendida/atascada indefinidamente. Por otro lado, si la orden es demasiado pequeña para el tamaño del fondo de liquidez, la utilización de la liquidez es muy baja e ineficiente. Este círculo vicioso destaca aún más que este enfoque de protocolo de liquidez para el diseño de puentes es ineficaz y fundamentalmente incorrecto.

Resolviendo el problema de seguridad

Tan importante como es este tema, la insostenibilidad económica no es el único desafío principal aquí. Incluso suponiendo que los puentes descubrieran una manera de utilizar el enfoque de liquidez bloqueada y mantenerse eficientes en cuanto al capital, a estas alturas, es evidente que crear un protocolo de liquidez seguro es una tarea que consume todo. De hecho, al convertirse, consciente o inconscientemente, en protocolos de liquidez, los proyectos puente se están dando a sí mismos la inmensa tarea de salvaguardar una superficie de ataque multifacética.

Para comenzar en un nivel alto, uno de los problemas evidentes con un puente de estilo de liquidez bloqueado es que crea un efecto multiplicador de riesgo, donde las vulnerabilidades de una cadena respaldada pueden extenderse y comprometer el capital mantenido en otros ecosistemas.

Aquí está el tema de la seguridad por proxy. Un puente puede ver comprometida toda su base de liquidez si existe una vulnerabilidad potencial en el código base de una cadena de bloques/L2 admitida. 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.

Nuevamente, cualquier problema con el mecanismo de consenso de una cadena también puede conducir a un contagio sistémico, poniendo en riesgo cualquier liquidez bloqueada en otras cadenas respaldadas. En este caso, el puente simplemente transmite el exploit a otras cadenas. Esto podría incluir ataques del 51 % u otras fallas a nivel de protocolo.

Aparte de estos tipos de riesgos heredados, estamos viendo cada vez más situaciones en las que los errores de los propios proyectos puente, de una forma u otra, han causado una pérdida de liquidez bloqueada. Desde actualizaciones de protocolo fallidas, diseño de contrato inteligente deficiente o infraestructura comprometida de validadores, hay muchos escenarios en los que los malos actores pueden explotar vulnerabilidades en el puente mismo.

Todos estos riesgos se agravan rápidamente y, como hemos visto en demasiadas ocasiones, finalmente los proveedores de liquidez los asumen cuando pierden la capacidad de rescate de sus activos envueltos. Tal posibilidad debería ser inaceptable.

Pocos están negando la gran promesa de la interoperabilidad entre cadenas para impulsar la adopción de Web3 a nuevas alturas. Pero con el tamaño y la frecuencia de los exploits de puentes, se ha vuelto dolorosamente claro que el diseño fundamental de la tecnología de puentes debe reinventarse a partir de los primeros principios. El diseño del puente convertido en protocolo de liquidez simplemente no está funcionando.

¿Hay alguna forma en que podamos idear un enfoque fundamentalmente nuevo y único para el diseño de puentes, uno que elimine por completo los riesgos para los proveedores de liquidez, elimine los vectores de ataque y, al mismo tiempo, conserve el más alto nivel de eficiencia del capital?

Puede haber exactamente eso en un futuro cercano. En deBridge, estamos trabajando en un nuevo enrutamiento de liquidez entre cadenas que resuelve todos estos problemas. Manténganse al tanto.

Publicación de invitado de Alex Smirnov de deBridge Finance

Alex Smirnov es matemático, investigador, desarrollador y entusiasta de blockchain. Es el director ejecutivo y cofundador de deBridge, un protocolo de interoperabilidad entre cadenas y mensajería genérica, donde se centra en el diseño de protocolos, la gestión de productos, las asociaciones y las operaciones. Alex cofundó Phenom, una empresa de investigación y desarrollo de cadenas de bloques, y también dirigió un equipo que ganó numerosos hackatones y desarrolló varias soluciones de cadenas de bloques y dApps.

Más información →

Sello de tiempo:

Mas de CryptoSlate