Cómo Connext permite la interoperabilidad entre cadenas con el estándar xERC-20

Connext, el protocolo modular de interoperabilidad que fue pionero en la Abstracción de Cadenas (Chain Abstraction), se dedica a simplificar la experiencia de usuario en el ecosistema blockchain, eliminando las complejidades asociadas al uso de múltiples blockchains.

El protocolo Connext, desarrollado sobre Linea zk-EVM, lo logra a través de diversas iniciativas, entre ellas el estándar de tokens xERC20 y el kit de herramientas de abstracción de cadenas, todos orientados a minimizar la necesidad de que los usuarios comprendan o incluso sean conscientes de las redes subyacentes con las que interactúan. En pocas palabras, Connext simplifica las transacciones entre cadenas y mejora la accesibilidad para hacer que la tecnología blockchain sea más accesible para el usuario promedio. En el núcleo de Connext se encuentran dos protocolos fundamentales.

El primero es la capa de mensajería subyacente, que lee el estado de múltiples rollups mientras los une y agrupa en un único enunciado combinado, de forma similar a como funcionan los secuenciadores de rollups. Esto garantiza que cualquier información disponible en una cadena también lo esté en las demás.

El segundo componente es el protocolo de intención, que permite a un usuario de Connext sin fondos en la cadena A completar una transacción utilizando liquidez externa de actores de mercado externos (solvers) en esa cadena. De este modo, el usuario de Connext no necesita preocuparse por el proceso de hacer bridge de sus tokens de la cadena B a la cadena A, sino que puede expresar su intención y un solver intervendrá en su nombre para financiar la transacción de inmediato, siendo reembolsado por el protocolo posteriormente.

El desafío de hacer bridge de tokens entre múltiples cadenas en web3

Los tokens ERC-20 nunca fueron diseñados para ser transferidos mediante bridges. En cambio, estaban pensados para residir en una sola cadena, razón por la cual no cuentan con funciones nativas de mint o burn. Cuando hoy se hace bridge de un token ERC-20, en segundo plano, el token queda bloqueado en un bridge mientras este acuña una attestation del token bloqueado en otra cadena. Esto significa que si el bridge es hackeado y los fondos son drenados, el valor del token ERC-20 dejará de estar respaldado, provocando que la attestation pierda su valor.

Otro desafío implica hacer bridge de tokens ERC-20 específicos de proyectos, lo cual ha sido históricamente complicado debido a la baja adopción y los enormes requisitos de liquidez. Los usuarios pueden utilizar un canonical bridge para hacer que los tokens sean interoperables o estén disponibles en diferentes cadenas; sin embargo, esto requiere que otros bridges adquieran el token nativo del canonical bridge para interactuar con dichos tokens.

Como alternativa, el uso de un bridge de terceros limitaría a los usuarios a un único ecosistema y basaría la seguridad de un proyecto enteramente en ese bridge. Ninguna de estas soluciones es ideal y todas imponen limitaciones a los proyectos.

El estándar de token xERC-20 y cómo habilita la interoperabilidad

xERC-20 es un estándar que resuelve este problema ofreciendo opcionalidad: en lugar de bloquear tokens ERC-20 en un bridge, se bloquean en un "lockbox", que es esencialmente un contrato wrapper. Este contrato wrapper acuña entonces un token xERC-20 con funciones tanto de burn como de mint, lo que permite a los bridges gestionar estas acciones de manera eficiente. Dado que estos tokens ERC-20 en L1 están bloqueados en un lockbox, en L2 se puede tener una representación consistente, lo que significa que independientemente del L2 que se utilice, se obtendrá siempre el mismo token.

Esta solución no es novedosa, ya que ha sido técnicamente viable desde hace algún tiempo. Sin embargo, el problema de esta solución radica en los riesgos de seguridad que introduce, donde múltiples bridges controlan el minting de tu token, exponiéndolo a problemas de seguridad si uno de los bridges es hackeado. xERC-20 aborda este problema de seguridad introduciendo límites de minting, donde un emisor puede asignar límites ajustables a la cantidad de tokens que un bridge puede acuñar.

Empieza a desarrollar en web3 con MetaMask Developer

¿Eres un desarrollador web3 creando dapps para usuarios finales?

La suite MetaMask Developer, que incluye la MetaMask Wallet API, el SDK, las APIs de servicios web3 y Snaps, ofrece un conjunto completo de herramientas para incorporar a millones de los usuarios más activos de la web. Visita el portal para desarrolladores para obtener más información sobre nuestras soluciones.