Un puente entre las cadenas EVM personalizadas y la liquidez de Tron | Entrevista con Andrew Nalichaev

29 de abril de 2026

Resumir con IA

En esta conversación, Andrew analiza en profundidad lo que significa conectar una cadena EVM personalizada a la liquidez de Tron. Habla de la seguridad de los puentes, las vulnerabilidades de los casos límite, los límites de las auditorías y las ventajas y desventajas de los modelos LP, lock-and-mint, intent-based e híbridos, centrándose en lo que realmente se rompe en producción y por qué.

Si trabaja con cadenas personalizadas, interoperabilidad o enrutamiento de liquidez, este es un desglose a nivel profesional de las decisiones que subyacen a la infraestructura de cadenas cruzadas.

Texto de la entrevista

Explique con más detalle el caso CrossCurve de febrero de 2026. Qué falló exactamente y cómo deberían cambiar incidentes como este nuestra forma de pensar sobre los puentes entre cadenas?

Creo que es una pregunta brillante, porque estamos asociados con CrossCurve y utilizamos su solución para algunos de nuestros clientes. Definitivamente, cuando ocurrió el accidente, realmente tratamos de evaluar cómo afectaba a nuestros clientes y a nuestras asociaciones. Y después de una comprobación interna, reconocimos que la buena noticia es que no tiene ningún impacto en nuestros clientes específicos.

¿Qué ocurrió en realidad? Así, CrossCurve utilizó algunos mensajeros externos que deben enviar un mensaje de la cadena de origen a la cadena de destino. Lo que realmente significa es que CrossCurve dijo que tienen, y de hecho tienen, la solución llamada puente de consenso. Eso en realidad significa que utilizan diferentes mensajeros a la vez para proteger la transacción específica, el proceso de lock-and-mint, o el proceso de transferencia de liquidez a través de las cadenas. Pero en este caso concreto, tuvieron que empaquetar estas dos cadenas diferentes, por lo que utilizaron sólo la solución Axelar.

Y el problema no está en CrossCurve, sino en el mecanismo de mensajería Axelar. ¿Qué significa esto en la práctica? Cuando alguien envía una transacción de la cadena de destino a la cadena de origen, la cadena de origen sólo comprueba el ID de la transacción en la cadena de destino y compara los números, sin verificar realmente el mensaje de la cadena de origen. Por desgracia, muchos auditores e investigadores no mencionaron esto como una vulnerabilidad. Por ello, CrossCurve se limitó a utilizar la misma solución y los métodos aprobados por los auditores externos.

Básicamente, nos demuestra que a veces ni siquiera podemos confiar plenamente en los auditores y necesitamos hacer una doble comprobación cada vez. Tal vez aplicar algunos controles adicionales de IA o lo que sea. Pero la buena noticia es que CrossCurve sigue en el juego. Y definitivamente, hay malas noticias al respecto, pero eso no significa que tenga problemas desde el punto de vista de la arquitectura. Podemos pensar en ello como un recordatorio de cómo alguien puede abusar y atacar los puentes. Pero aún así, sólo significa que tenemos que hacer algunas comprobaciones dobles, tener en cuenta que estos ataques pueden ocurrir, y construir las próximas soluciones y puentes a través de la cadena de forma más segura.

Muchos fallos de puentes se describen como “casos límite”. ¿Son estos incidentes realmente casos extremos, o síntomas de problemas arquitectónicos más profundos?

Depende de cada caso. Puedo decir que los problemas arquitectónicos más comunes se resolvieron durante el anterior mercado alcista, en algún momento entre mediados de 2020 y 2021. Así que los casos más comunes ya se han resuelto. Pero algunos casos son realmente casos límite. Por ejemplo, el caso de CrossCurve. Creo que es un verdadero caso límite porque incluso después de todas las comprobaciones, incluso con una buena arquitectura y una idea absolutamente brillante, siguen existiendo esos puntos débiles.

Y definitivamente, creo que ahora mismo ya tenemos la solución arquitectónica más común que puede haber. Lo llamamos un estándar de oro para la industria, y en general, es un estándar común, creo. Por lo tanto, no podemos decir que hay problemas arquitectónicos totalmente con él. Podemos decir que algunos pequeños fallos o pequeños casos inusuales, y lo que en realidad llamamos un caso límite, pueden ocurrir.

Creo que nuestro principal objetivo en este momento es prevenir y proteger contra estos casos extremos a nivel arquitectónico. Es factible, por ejemplo, utilizar una solución híbrida, una doble comprobación, una auditoría adicional o tal vez un enfriamiento en algunos casos. En nuestra empresa, realmente intentamos aplicar cada vez más controles y protecciones de seguridad, y a veces incluso preferimos reutilizar soluciones existentes en lugar de crear puentes desde cero.

Y en este caso, sin duda es mejor aplicar la norma principal en lugar de intentar reinventar la rueda.

Tron desempeña un papel único en los flujos de stablecoin, especialmente para USDT. Por qué el enrutamiento de Tron a EVM introduce riesgos diferentes que el puente de EVM a EVM?

Creo que es la pregunta que nos hace cualquiera de nuestros clientes, o incluso cualquiera que decida crear su propia cadena personalizada. En la mayoría de los casos, serán cadenas compatibles con EVM, a veces ZK-rollup de capa 2 u Optimistic rollup. Y todo el mundo quiere tener una parte de la liquidez de la cadena Tron porque sigue desempeñando un papel importante en las transferencias de stablecoins: alguien cobra, recibe un salario o paga facturas utilizando stablecoins en Tron.

Definitivamente, cualquiera quiere tener acceso a esta liquidez y utilizarla en su propia cadena personalizada. Las cadenas compatibles con Tron y EVM tienen diferentes tipos de direcciones, diferentes tipos de contratos inteligentes y diferentes lenguajes para los contratos inteligentes. Y por eso es tan difícil. Si conectamos la cadena EVM a la cadena EVM, la dirección en la cadena de destino y en la cadena de origen será la misma, y podremos utilizar el mismo contrato inteligente para lock-and-mint, incluso desde el punto de vista de los pagos por las tasas de transacción.

Así, en una cadena EVM, tenemos el mismo mecanismo para estimar las tasas de gas y los costes de transacción. En Tron, es absolutamente diferente, con un concepto de energía, con pago en algunos TRX, etc. Por eso es tan diferente y más complejo, en lugar de limitarse a conectar dos cadenas diferentes compatibles con EVM.

Los puentes de LP se consideran la opción más “autóctona”. ¿En qué momento el requisito de liquidez de este modelo se convierte en una limitación estructural y no en un obstáculo temporal?

Sinceramente, creo que los puentes LP son el enfoque más clásico para muchas cadenas. Significa que usted, como alguien que quiere emparejar su cadena con una externa, o como propietario del puente, no necesita proporcionar su propia liquidez. Puede pedir a la comunidad que le proporcione esa liquidez y, en la mayoría de los casos, aceptarán compartirla con usted.

Pero tienes que proporcionarles algún beneficio. Y competirás con los protocolos DeFi existentes u otros casos de uso de la liquidez. Significa que su puente debe tener muchos TVL bloqueados y muchas transacciones cruzándolo. Si el volumen de transacciones es realmente alto y cobra muchas comisiones, podrá compartirlas con los proveedores de liquidez.

De lo contrario, en un caso en el que tendrá menos transacciones, eso significa que el proveedor de LP tiene menos motivos para proporcionar liquidez porque cobrará menos de las comisiones. Por eso pueden decidir simplemente retirar liquidez de su puente y utilizarla en un protocolo DeFi externo. En este caso, el deslizamiento en esta transacción LP, con este puente utilizando LP, será mayor.

Por eso alguien puede decidir: “Vale, no quiero hacer la transacción en esta cadena con este puente y prefiero otra opción”.” Así que tienes que jugar con la liquidez, y tienes que dar cada vez más razones para apoyar tu solución puente con la liquidez.

Los puentes de bloqueo y acuñación eliminan la necesidad de liquidez mancomunada, pero introducen activos envueltos. Según su experiencia, ¿dónde tienden a fallar primero estos puentes: técnica, económica o socialmente?

Definitivamente no desde el punto de vista social. Sabes, la mejor parte de la estrategia del cerrojo y la menta es que no tienes liquidez en absoluto.... En el caso de los puentes LP, es necesario pedir a alguien que proporcione la liquidez para los LP. En este caso, ni siquiera es necesario disponer de liquidez propia.

Si alguien quiere utilizar algunas stablecoins o su cadena, podrá bloquear un cierto número de stablecoins, o la moneda que sea, en la cadena de origen y acuñar un número igual en su cadena personalizada o, en general, en la cadena de destino.

Pero, ¿cuál es el problema? El mayor problema de este enfoque es que puede crear un tipo diferente de token en la cadena de destino. Así que se trata de la fragmentación de la liquidez. Por ejemplo, tendrás una versión del token de Ethereum y otra de Arbitrum, o diferentes tipos de tokens emitidos por diferentes puentes con un enfoque de lock-and-mint. Así que se trata de fragmentación.

Pero también se enfrenta a algunos problemas desde el punto de vista técnico, porque si alguien ataca al mensajero y envía el mensaje equivocado de que hay que desbloquear cierta cantidad de tokens en la cadena de origen o emitir un número adicional de tokens en la cadena de destino, entonces podrá obtener la liquidez adicional que no está garantizada por los tokens reales en la cadena de origen.

Así que es un gran problema, y en la mayoría de los casos, si alguien intenta atacar esos puentes, combina un ataque económico con uno técnico, pero no social.

La ejecución basada en la intención promete una buena experiencia de usuario y bajos costes. Dónde empieza a romperse este modelo cuando aumentan los volúmenes o cambian las condiciones del mercado?

Estoy de acuerdo en que un enfoque basado en la intención puede ser el mejor desde el punto de vista de la experiencia del usuario. Pero si creas tu propia cadena, significa que tienes que proporcionar motivación adicional a algunos bots, algoritmos o incluso personas para que sean los solucionadores, porque los solucionadores son un componente clave del enfoque basado en la intención.

Para muchos de nuestros clientes, utilizamos 1inch Fusion+. Es exactamente un enfoque basado en la intención. Pero si quieres utilizarlo para tus propias cadenas personalizadas, tienes que motivar a alguien para que sea este solucionador. Por ejemplo, si ven cada vez menos volumen de transacciones en tu cadena y cada vez menos gente que quiere hacer esta transferencia puente, pueden intentar dictarte sus expectativas desde el punto de vista de los ingresos, y entonces la experiencia del usuario es cada vez peor.

Y este bajo coste puede ser cada vez mayor, y la velocidad de transacción puede ser más lenta. Puede que seas el único solucionador o resolutor que opere con ese enfoque. Así que creo que es lo peor del enfoque basado en la intención.

El modelo híbrido desplaza la liquidez fuera de la red de destino. Qué riesgos elimina realmente y cuáles concentra en cambio?

Si hablamos de puentes en general, si creas tu propia cadena personalizada, querrás conectarla al ecosistema externo. En la mayoría de los casos, estoy bastante seguro de que en realidad no quieres conectar una sola cadena a una sola cadena externa.

Pero si utilizamos el enfoque LP o el enfoque de bloqueo y acuñación, significa que tienes que conectar tu única cadena a muchas cadenas, lo que es realmente costoso y requiere mucha liquidez. En la mayoría de los casos, lo normal es elegir una cadena como cadena de origen y conectarla a tu cadena. Y en este caso, con su cadena de destino, puede ser un enfoque de cerradura y menta.

Pero esta cadena externa puede conectarse a muchas, muchas, muchas otras cadenas externas de diferentes maneras. Por ejemplo, con el enfoque LP o con un enfoque basado en la intención. Si crea su propio L2 ZK-rollup y desea acceder a liquidez del ecosistema externo, puede utilizar Arbitrum como cadena fuente.

Arbitrum puede conectarse a Tron a través de un enfoque basado en la intención y a Ethereum a través de un enfoque LP. Y luego esta última milla será sólo un enfoque de bloqueo y menta a su cadena. Así pues, la solución híbrida le permite acceder a cualquier liquidez externa en cadenas externas, pero con una cadena intermedia que utilizará como fuente para su propia cadena personalizada.

Si un equipo está diseñando una ruta Tron-EVM stablecoin ahora, en 2026, ¿cuál es la primera pregunta incómoda que deberían obligarse a responder antes de elegir un enfoque?

Creo que la pregunta más incómoda es: ¿cuánto estás dispuesto a gastarte en esta solución puente? ¿Y cuánto dinero está dispuesto a destinar a alguna solución? Si hablamos de un enfoque basado en la intención, significa que desde el principio tendrá que ofrecer patrocinios u otra razón para que los solucionadores sigan siendo solucionadores en su cadena. Si el tráfico a través de su cadena no es el mayor desde el primer día, realmente necesitará patrocinar su solución. Si dejas de hacerlo, en la mayoría de los casos, pueden decidir desactivar su solución.

De lo contrario, si estamos hablando de un enfoque de "cerradura y menta", tendrás que pagar algo de dinero a los mensajeros conocidos existentes para conectar tu cadena a su red de mensajeros. Y es mucho. Es decir, pagarás cientos de miles de dólares sólo para estar conectado, y es un pago único.

Si hablamos del enfoque LP, básicamente puede proporcionar su propia liquidez. Y sigue significando que puede ser el único proveedor de LP para este enfoque, pero esta liquidez estará bloqueada. O pagará a alguien para que bloquee la liquidez, lo que también significa que tendrá que gastar parte de sus propios tokens o, en el mejor de los casos, un patrocinio adicional por la liquidez bloqueada.

Así que, para mí, la primera y más importante pregunta es cuánto estás realmente dispuesto a gastar en ello, y cuánto dinero y fichas estás dispuesto a destinar a este tipo de soluciones.

Conozca al entrevistado

Andrew Nalichaev

Experto en Blockchain y analista de DeFi

Andrew traduce conceptos descentralizados en herramientas financieras seguras y funcionales. Navega por el volátil panorama DeFi para construir infraestructuras de blockchain escalables que aborden la utilidad del mundo real, pasando de las palabras de moda para ofrecer valor técnico.

Ver perfil

La experiencia de Andrew en acción

Más sobre este tema

Blog

Cómo mover USDT de Tron a EVM sin quedar atrapado por la liquidez

Blog

Coste de desarrollo de criptointercambios en 2026: desglose CEX frente a DEX

Blog

Top Layer 2 blockchains: encuentre la que mejor se adapte a su proyecto

Contáctenos

Reserve usted una llamada o rellene usted el siguiente formulario y nos pondremos en contacto con usted cuando hayamos procesado su solicitud.

Nombre

Empresa

Correo electrónico

Teléfono

Mensaje

Envíenos un mensaje de voz

Adjuntar documentos

Cargar archivo

Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

Al hacer clic en Enviar, autoriza a Innowise a procesar sus datos personales de acuerdo con nuestra política de privacidad. Política de privacidad para proporcionarle información relevante. Al enviar su número de teléfono, acepta que nos pongamos en contacto con usted a través de llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas de llamadas, mensajes y datos.

También puede enviarnos su solicitud
a contact@innowise.com

¿Qué pasa después?

Una vez recibida y procesada su solicitud, nos pondremos en contacto con usted para detallarle las necesidades de su proyecto y firmar un acuerdo de confidencialidad. Proyecto y firmaremos un acuerdo de confidencialidad.

Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados con el alcance del trabajo, el tamaño del equipo, el tiempo y las estimaciones de costes.

Concertaremos una reunión con usted para hablar de la oferta y concretar los detalles.

Por último, firmaremos un contrato y empezaremos a trabajar en su proyecto de inmediato.