Si no has leído la Parte I de la serie Cómo hacer que los tokens de cadena cruzada vuelvan a ser fungibles, es posible que desees hacerlo échale un vistazoprimero, se explica por qué los tokens puente pierden fungibilidad y los desafíos que esto crea. En la Parte II, exploramos ERC-7281, un nuevo estándar que simplifica las transferencias de tokens entre cadenas, mejora la confiabilidad y brinda a los emisores un mayor control.

La necesidad de un mejor enfoque

Hasta ahora, hemos explorado varias soluciones al problema de hacer que los tokens puenteados sean fungibles y resolver problemas relacionados con la fragmentación de la liquidez y la mala experiencia de usuario a partir de representaciones no canónicas de un token nativo que circula en cadenas de bloques no nativas:

• Crear representaciones canónicas de un token en cadenas remotas a través de puentes de rollup/cadena lateral canónicos
• Acuñar representaciones canónicas de un token en cadenas remotas a través de un servicio de puente de terceros
• Crear representaciones canónicas de un token en cadenas remotas a través de un servicio de puente canónico operado por el emisor del token

Cada uno de estos enfoques muestra compensaciones, por lo que es lógico que la propuesta de ERC-7281 para crear tokens puentes fungibles intente aprovechar lo mejor de cada enfoque para crear una solución más holística, eficiente y accesible para los protocolos que desean implementar tokens entre cadenas sin sacrificar la seguridad, la soberanía o la experiencia del usuario.

ERC-7281: Tokens soberanos interconectadoses una propuesta para habilitar la creación de representaciones canónicas de un token que son compatibles e intercambiables con las representaciones acuñadas por muchos puentes diferentes. ERC-7281 funciona mediante la extensión de la interfaz ERC-20 para incluir:

• Funcionalidad para acuñar y quemar tokens ERC-20 canónicos;
• Capacidad del propietario del token para

1) asignar operadores de puente para acuñar y quemar tokens al ser puentes entre cadenas;

2) Limitar la creación y quema de tokens para cada operador de puente aprobado, por ejemplo, estableciendo límites bajos para puentes centralizados y más altos para protocolos más seguros.

Dada la ligera diferencia entre los tokens ERC-7281 y ERC-20, los autores de EIP han descrito a los primeros como "xERC-20". Para los lectores que requieren una visión general de los tokens ERC-20, OpenZeppelin tiene un excelente guía sobre el tema.

En esencia, cada contrato de token ERC-20 implementa la interfaz ERC-20 que define un suministro global de tokens y almacena información sobre qué direcciones poseen el token y cuánto poseen. ERC-20 también incluye funciones útiles para gestionar el acceso a los tokens de un usuario (a través de aprobaciones) y para recuperar información sobre un token, como el suministro circulante total y el saldo de una dirección específica.

Una característica adicional que ERC-7281 añade a la especificación ERC-20 es una Caja de Seguridad opcional que funciona como un contrato envolvente (similar al contrato WETH (Ether envuelto)). El contrato de Caja de Seguridad envuelve tokens ERC-20 en tokens xERC-20 a través de mecanismos familiares de creación y quema y hace que ERC-7281 sea compatible con contratos de tokens ERC-20 existentes que carecen de una interfaz de quema/creación y no son actualizables.

Usando el marco introducido en el artículo anterior, podemos categorizar ERC-7281 como un enfoque de "confiar en el emisor del token + confiar en el proveedor de puente (aprobado)" para la creación de tokens multichain. Un token ERC-7281 desplegado en varias cadenas está controlado por su emisor (a diferencia de diseños alternativos de tokens cross-chain que generalmente requieren ceder soberanía). Aunque el emisor sigue estando expuesto al riesgo de que un puente aprobado sufra un incidente de seguridad, el emisor gestiona este riesgo eligiendo manualmente y limitando la tasa de proveedores de puente autorizados.

La gran diferencia, que exploraremos en este informe, es que los emisores de tokens pueden calibrar la exposición a los hacks y exploits de los puentes imponiendo límites dinámicos sobre cuántos tokens puede crear/quemar un operador de puente en particular. ERC-7281 también permite a un emisor de tokens poner en lista blanca a múltiples proveedores de puentes para crear el mismo token canónico en diversas cadenas, reduciendo la dependencia de un único proveedor para procesar operaciones de cruce de puentes entre cadenas.

Ambas características hacen que ERC-7281 sea una mejora significativa con respecto a los enfoques tradicionales para facilitar el puente entre cadenas de los tokens de un protocolo y tienen efectos positivos de segundo orden para los usuarios, los proveedores de infraestructura de interoperabilidad (especialmente los agregadores) y los desarrolladores de aplicaciones. Después de analizar las especificaciones en la siguiente sección, revisaremos las ventajas y desventajas de implementar ERC-7281.

Una descripción general de ERC-7281: Tokens puenteados soberanos

Quemar y acuñar tokens para usuarios

En la especificación, un proyecto implementa un nuevo contrato de token compatible con ERC20 que implementa la interfaz IXERC20. Los operadores del puente emiten tokens para los usuarios en la cadena de destino después de quemar un depósito en la cadena de origen. El proceso de emisión verifica que la cantidad de tokens no exceda el límite del puente y actualiza el suministro total del token y el límite de emisión del puente si tiene éxito.

Para los tokens ERC-20 ya existentes, se aplica una lógica de "caja de seguridad": el proveedor del puente envuelve los tokens ERC-20 depositados por los usuarios en tokens xERC-20 transfiriéndolos a un contrato de caja de seguridad. A continuación, la Lockbox aprueba el puente para acuñar una cantidad equivalente de tokens xERC-20.

Los tokens xERC-20 emitidos por un puente en la cadena de destino se queman en la cadena de origen utilizando la función burn(). Este proceso asegura que la cantidad de tokens no exceda el límite de quema del puente, lo aumenta y disminuye el suministro total de tokens xERC-20. La capa de transporte del puente transmite el mensaje de quema al destino. El contrato del puente en el lado de destino verifica el mensaje y emite una cantidad igual de tokens xERC-20 a la dirección del usuario en esa cadena. Esta emisión disminuye el suministro total de tokens y el límite de emisión del puente.

Para llevar tokens de vuelta a la cadena de origen, el operador del puente quema tokens xERC-20 en la cadena remota, proporcionando la dirección del usuario y la cantidad de tokens. El recibo de quema se transmite a la cadena de origen a través de la capa de transporte. Si se verifica el mensaje de quema, el operador del puente emite y quema nuevos tokens xERC-20 en la cadena de origen para el usuario. Tras la validación del recibo de quema por el contrato del token, el operador del puente libera los tokens ERC-20 depositados al usuario. La quema de tokens xERC-20 en la cadena de origen reduce el suministro total de tokens y el límite de quema del puente.

Un punto importante: el contrato xERC-20 puede técnicamente crear tokens sin que el puente verifique las pruebas. Hemos descrito el enfoque estándar (léase: esperado), pero los puentes que no implementan ningún tipo de verificación de mensaje, o implementan mecanismos novedosos para verificar mensajes de cadena cruzada, pueden ser incluidos en la lista blanca para crear y quemar tokens xERC-20. Todo depende de lo que el emisor del token pueda aceptar.

Límites de velocidad para la acuñación y quema de tokens

La función setBridgeLimits es una función protegida que solo puede ser llamada por el propietario del contrato del token. Esta función permite establecer la dirección del contrato puente y especificar la cantidad máxima de tokens que el puente puede acuñar (mintingLimit) y quemar (burningLimit) para los usuarios. El propietario puede actualizar estos límites, lo que permite ajustar las capacidades del puente según sea necesario. Por ejemplo, si se descubren problemas de seguridad en la infraestructura de un proveedor de puentes, el mintingLimit se puede reducir para minimizar el riesgo. Por el contrario, las mejoras de seguridad pueden llevar a un aumento en el límite de acuñación.

La especificación xERC-20 también incluye funciones para verificar los límites de quemado y emisión para los puentes aprobados para manejar el token. "mintingMaxLimitOf" devuelve la cantidad máxima de tokens que un puente puede emitir, y respectivamente, "burningMaxLimit" devuelve la cantidad máxima de tokens que un puente puede quemar durante un período especificado. Además, estas funciones muestran los tokens restantes que un puente puede quemar y emitir antes de alcanzar los límites preestablecidos.

Estas funciones de visor son útiles para los agregadores de puentes que necesitan conocer los límites disponibles para diferentes proveedores de puentes antes de enrutar transacciones. Si un puente alcanza su límite de combustión o acuñación en la cadena de origen o destino, puede afectar a las transacciones en curso y a la experiencia del usuario. Por lo tanto, los agregadores prefieren enrutar las solicitudes a puentes que no han alcanzado sus límites de acuñación y quema y pueden realizar el intercambio de una cantidad determinada.

Parámetros de límite de tasa

La especificación de la interfaz de token xERC-20 incluye una estructura 'Bridge' que contiene 'burningParams' y 'mintingParams' (los parámetros de una función de límite de tasa de un token xERC-20 controlan cuántos tokens puede quemar y acuñar un puente en un período predefinido). 'maxLimit' define el límite máximo en la acuñación y quema de tokens y aumenta cada segundo a una tasa predefinida ('ratePerSecond').

Aquí es donde abordamos un posible punto de confusión: "maxLimit" (establecido para el límite de grabación y acuñación) suena como un límite en las operaciones de acuñación y grabación en una escala de tiempo determinada, no un límite de velocidad que limita la acuñación y grabación de acuerdo con umbrales predefinidos durante la ventana de tiempo preestablecida. "currentLimit" define cuánto puede acuñar o quemar un puente y aumenta a una tasa predefinida. Por el contrario, "maxLimit" define cuánto puede acuñar o quemar un puente diariamente.

Los parámetros de grabación y acuñación son principalmente relevantes para los propietarios de tokens (y, en menor medida, para los operadores de puentes). Sin embargo, los parámetros de límite máximo y actual son consideraciones importantes para los usuarios y los operadores de puentes. Por ejemplo, el límite actual podría afectar a la cantidad de confianza que un usuario puede conectar con un protocolo de cadena cruzada sin sufrir retrasos en la recepción de tokens xERC-20 en el destino.

Caja de seguridad xERC-20

El token ERC-20 original no especifica funciones para aumentar y disminuir la oferta de tokens (cuando “tokenomics” significaba generar una cantidad fija de tokens y decir a los usuarios que el token tenía valor porque sería escaso en unos pocos años*). Por lo tanto, no todos los tokens ERC-20 tienen una función de acuñación y quema. Dado que ERC-7281 utiliza el mecanismo de acuñación y quema favorecido por la mayoría (si no todos) de los puentes hoy en día, los tokens ERC-20 heredados o no actualizables no pueden funcionar directamente con ERC-7281.

El contrato de caja de seguridad proporciona una solución alternativa y permite la compatibilidad con versiones anteriores con los tokens existentes. En la especificación original (es decir, un proyecto despliega un nuevo contrato de token que implementa la interfaz IXERC20), los operadores de puentes solo tienen que llamar a mint() para acuñar tokens para un usuario en la cadena de destino (después de bloquear un depósito en la cadena de origen).

El contrato Lockbox se inspira en gran medida en el diseño del contrato de envoltura WETH. Implementa una función deposit() para depositar el token ERC-20 correspondiente en el Lockbox y una función withdraw() para que los operadores de puente desbloqueen los tokens ERC-20 después de quemar tokens envueltos en un dominio remoto.

Los dos primeros tipos de error resaltados en la especificación ("IXERC-20Lockbox_NotNative" e "IXERC-20Lockbox_Native") se producen cuando un usuario intenta depositar tokens en el contrato de Lockbox incorrecto. Una caja de seguridad puede ser nativa o no nativa, en función de los tipos de tokens que admita.

Las cajas de seguridad nativas custodian tokens nativos, es decir, tokens utilizados para pagar comisiones de gas a los validadores. Un ejemplo de un token que tendría una caja de seguridad nativa para envolverlo en un token xERC-20 es ETH: envolver ETH en un token xERC-20 requeriría llamar a la función depositNative() de la caja de seguridad y depositar ETH para recibir la representación compatible con ERC7281 de ETH.

Las cajas de seguridad regulares (no nativas) custodian tokens ERC-20 como USDC, DAI, WETH, USDT, etc. Para acuñar USDC como un token xERC-20, por ejemplo, el usuario llamaría a deposit() en el contrato de Lockbox después de bloquear USDC.

Llamar a deposit() con ETH resultaría en que esos fondos se bloqueen para siempre, ya que el contrato de Lockbox regular solo puede envolver y desenvolver tokens ERC-20. Llamar a depositNative() con un token ERC-20 produciría resultados similares, ya que los contratos de Lockbox nativos están destinados a funcionar con tokens nativos, no con tokens ERC-20.

De esta manera, al envolver tokens ERC-20 canónicos en tokens xERC-20 con soporte de emisión/quema, el Lockbox proporciona una capa de compatibilidad importante para el estándar. Sin embargo, en algunos casos, como la integración de otras soluciones de puente en xERC-20, simplemente utilizando el candado y devolviendo el token envuelto no es una opción. Por esta razón, los proyectos pueden implementar contratos adaptadores.

Contratos de adaptadores

En los casos en los que los protocolos de puente no están diseñados para reconocer las operaciones inherentes a los tokens xERC-20 (acuñación/grabación, registro correspondiente, etc.), las aplicaciones pueden crear contratos de adaptador. Estos contratos funcionan como envoltorios y desenvoltorios automatizados, lo que traduce de manera efectiva el comportamiento de aprobación + llamada estándar de ERC-20 en un esquema de acuñación/quema más matizado requerido por xERC-20.

Esto es necesario porque muchos protocolos de puente (por ejemplo, el CCIP de Chainlink) siguen optimizados para el comportamiento convencional de ERC‑20. El contrato del adaptador puede cerrar (ba-dum-tss) esta brecha de compatibilidad al consagrar tal lógica: deposita tokens en el Lockbox para generar la representación xERC‑20 en la cadena de origen, y más tarde, al recibir el mensaje en la cadena de destino, activa el mecanismo de retiro para volver al activo canónico.

Este flujo garantiza que, en última instancia, el usuario reciba un token canónico y coherente, que no se vea afectado por los mecanismos de envoltura impulsados por xERC-20 bajo el capó. De esta manera, los adaptadores pueden permitir que los protocolos se integren sin problemas con puentes que no cumplan con xERC-20 y aumentar el espectro de soluciones interoperables que admiten.

¿Por qué ERC-7281? El caso de un estándar de token puente soberano

A un alto nivel, ERC-7281 tiene cuatro objetivos generales:

1. Fungibilidad: Los usuarios que conecten tokens de la cadena nativa del token a otra cadena (L1/L2) siempre deben recibir representaciones canónicas del token puenteado en el destino. Múltiples versiones no fungibles del mismo token que circulan en una cadena no nativa son problemáticas por las razones explicadas anteriormente (por ejemplo, fragmentación de la liquidez y poca componibilidad del token).

La visión original de crear la especificación ERC-20 era garantizar la fungibilidad y la interoperabilidad entre tokens en Ethereum a través de aplicaciones e infraestructura de Ethereum. Sin embargo, tras adoptar una hoja de ruta de escalado centrada en rollup, surgió el problema de la falta de composabilidad atómica, y la creación de muchos dominios diferentes degradó esas propiedades de fungibilidad. xERC-20 permite agregar la liquidez de varios puentes cross-chain en rollup en tokens multi-rollup unificados, restaurando la visión inicial de Ethereum.

1. Seguridad: Para reducir el riesgo de contraparte, los emisores de tokens deberían tener la opción de seleccionar entre proveedores de puente competidores según la evaluación de la infraestructura de seguridad. Además, los emisores de tokens deberían tener una protección significativa ante las consecuencias de incidentes de seguridad que afecten a los proveedores de puentes asociados: los ataques aislados a uno o dos servicios de puente no deberían eliminar por completo los TVL.

2. Bootstrapping sin liquidez para tokens cross-chain: Las DAO de protocolo no deberían verse obligadas a gastar importantes recursos (financieros) en el bootstrapping de liquidez para tokens puenteados como parte de los planes de expansión multicadena. Los puentes basados en la liquidez no solo son pobres para la UX, sino que el gasto en incentivos de provisión de liquidez puede volverse inviable para los equipos de proyecto a medida que la cantidad de cadenas de bloques aumente en breve.

3. Soberanía para los emisores de tokens: El emisor de tokens debe mantener el control de la representación canónica de los tokens de protocolo acuñados en cadenas no nativas. Resolver el problema de los tokens puenteados no fungibles no debería requerir transferir el control del token puente de un proyecto, especialmente los aspectos administrativos como el control del suministro total y la configuración de los mecanismos de acuñación y quema, a un puente de terceros.

Podemos ampliar aún más estos objetivos para ver qué beneficios ERC-7281 proporciona a los protocolos y comunidades.

Analizando los beneficios de ERC-7281

Mejorar la experiencia de usuario y eliminar la fragmentación de la liquidez

ERC-7281 resuelve varias versiones del problema de dependencia de ruta descrito en la introducción.

La dependencia de la ruta puede ser específica de la cadena (por ejemplo, ETH puenteado desde Ethereum → Arbitrum → Optimism es diferente de ETH puenteado desde Ethereum → Optimism → Arbitrum) o específico del puente (por ejemplo, ETH puenteado desde Ethereum a Optimism a través de Celer es diferente de ETH puenteado desde Ethereum a Optimism a través de Connext).

La dependencia de la ruta es una característica de seguridad valiosa, pero también puede ser perjudicial para unir la experiencia de usuario y la componibilidad entre cadenas. Por ejemplo, un usuario no puede suministrar liquidez de forma programática a un DEX de cadena cruzada que opera en Optimism y Arbitrum, ya que la aplicación debe aceptar opETH o arbETH.

ERC-7281 elimina el problema al introducir tokens xERC-20 que siguen siendo fungibles sin importar cuántas veces un usuario haga puentes a través de cadenas o qué proveedores de puentes se utilicen para puentear tokens. Supongamos que un usuario desea mover USDT envueltos de Arbitrum a Optimism sin retirarse primero a Ethereum; un proveedor de puentes puede quemar tokens xERC-20 en Arbitrum y acuñar xERC-20 en Optimism: el valor de los tokens acuñados en Optimism todavía está vinculado a los tokens depositados en la Lockbox y se reasignan para mantener su respaldo 1:1.

Es importante destacar que ERC-7281 ofrece los beneficios de implementar un token puente canónico como CCTP de Circle (Protocolo de Transferencia Cross-Chain) sin necesidad de que el protocolo tenga custodia centralizada de los tokens puente. Por ejemplo, la liquidez se consolida alrededor de la representación canónica del token de un proyecto, lo que mejora la utilidad del token para aplicaciones de DeFi y reduce la carga de crear diferentes mercados para diferentes versiones del mismo activo.

Refuerzo de la soberanía de los emisores de tokens

Los xERC-20 se describen como "tokens puente soberanos" ya que los emisores de tokens no están obligados a utilizar una opción particular para acuñar representaciones canónicas de un token y mantienen el control del diseño y la administración de tokens puente en implementaciones. ERC-7281 es un híbrido entre "acuñar tokens canónicos a través de un puente de un tercero" y "acuñar tokens canónicos a través de un puente controlado por el emisor de tokens" que combina soberanía, experiencia de usuario y descentralización en el mismo paquete.

Los proyectos que despliegan tokens cross-chain con ERC-7281 pueden generar representaciones canónicas de tokens nativos a través de múltiples puentes sin encontrarse con el problema de versiones envueltas no fungibles del mismo activo nativo, rompiendo la experiencia de usuario para aquellos que esperan aprovechar la composabilidad y fungibilidad de los tokens ERC-20. Dichos proyectos también mantienen un nivel similar de control sobre los despliegues cross-chain de un token como emisor de tokens que ejecuta infraestructura interna para gestionar transferencias de tokens canónicos entre dominios, ya que los contratos de tokens xERC-20 y Lockbox, que los puentes utilizan para bloquear, generar y quemar tokens para los usuarios, son desplegados y controlados por el proyecto.

Esta característica discreta puede ser útil en los casos en que un proyecto de alto perfil tiene un token nativo emitido en la cadena de origen. Los usuarios de otros ecosistemas quieren exponerse al token sin tenerlo en su cadena nativa por diferentes razones.

Aún así, el proyecto no tiene la capacidad o la voluntad de ejecutar una infraestructura de puente interna para cada cadena para garantizar la compatibilidad 1:1 entre los tokens puenteados, ni quiere transferir el control de su token a un tercero que no esté necesariamente alineado con el protocolo y su comunidad. Tal caso se convierte en una consideración cuando se implementa la gobernanza entre cadenas que permite votar con tokens puenteados mientras los votos se cuentan en la cadena nativa; Un proveedor de puentes no alineado con control de tokens puenteados se convierte en un cuello de botella para la gobernanza del protocolo.

Beefy, un protocolo de agricultura de rendimiento, también ha adoptado xERC-20 por esta razón. Como lo describe la documentación del puente del proyecto, ERC-7281 proporcionó al proyecto más opciones para el puente de tokens, lo cual se hizo necesario después de que un importante socio del puente sufriera un hackeo (un tema que está volviéndose rápidamente familiar para los nativos de la criptografía) y proporcionó un control más detallado del diseño de los mecanismos de puente. En el caso de Beefy, la función de inclusión en la lista blanca de ERC-7281 permitió al protocolo seleccionar varios socios de puente y ofrecer a los usuarios diferentes opciones entre optimizar la velocidad, la descentralización, los costos y la seguridad al puente de tokens mooBIFI.

La realineación de incentivos mejora la competencia abierta y la seguridad

El puente basado en la liquidez a menudo favorece a los proyectos con la capacidad financiera para gastar en incentivos de liquidez: dado que los emisores de tokens quieren gastar poco en incentivos de LP y ofrecen una experiencia de usuario puente superior, la liquidez se convierte en el factor más crucial para los protocolos que utilizan puentes L1/L2 canónicos. Esto también se extiende a la selección de proveedores de puentes por parte de los agregadores de puentes, lo que podría dificultar que los nuevos servicios de puente (incluso aquellos con infraestructura segura) compitan con protocolos de puente más establecidos.

ERC-7281 soluciona el problema al eliminar la necesidad de puentes basados en liquidez. Sin la necesidad de acuñar e intercambiar tokens no canónicos por tokens canónicos, se pueden aprobar puentes de cualquier tamaño para acuñar el token de un proyecto en un dominio remoto. Dado que los emisores de tokens quieren minimizar la exposición a los fallos de los puentes, es probable que más protocolos empiecen a prestar más atención a los diseños de seguridad de los puentes entre cadenas en lugar de centrarse primero en la liquidez.

Esto incentiva la competencia abierta, ya que se convierte en un caso de "que gane el puente más seguro" y no de "que gane el puente más líquido"; esta competencia abierta puede tomar la forma de puentes que compiten en más características más allá de la liquidez/seguridad (por ejemplo, tarifas, API/SDK, integraciones de aplicaciones, etc.). Podría decirse que estas características son más fáciles de incorporar a una aplicación desde el principio, ya que dependen principalmente de la experiencia del equipo de desarrollo; Por el contrario, la liquidez y los volúmenes puente son más complejos de arrancar y requieren una combinación de desarrollo comercial, financiación, conexiones con la industria, marketing y más.

Mejor gestión de riesgos para emisores de tokens

ERC-7281 introduce un límite de tasa configurable en la acuñación y quema de tokens que mejora drásticamente el perfil de riesgo para los protocolos que trabajan con puentes de terceros para acuñar tokens canónicos en cadenas no nativas. En caso de que un proveedor de puente asociado sea hackeado o comprometido, el mayor daño que puede causar un atacante es equivalente al límite asignado al puente comprometido. Si un emisor de tokens elige cuidadosamente los parámetros de limitación de velocidad, los ataques aislados en un puente deberían tener un impacto mínimo en la solvencia del protocolo.

La configuración de límites de tasa por puente también puede mejorar el proceso de evaluación de riesgos para protocolos DAO. Actualmente, la evaluación de riesgos del puente puede tardar meses en completarse debido a la magnitud del impacto de que un puente de terceros canónico sea pirateado; los protocolos quieren asegurarse de tomar decisiones defendibles, donde la seguridad del puente elegido se examina exhaustivamente para brindar a la comunidad garantías más sólidas de seguridad. Además de ser innecesariamente derrochador de esfuerzo y tiempo, los análisis maratónicos de la seguridad del puente aún no garantizan que un puente elegido sea inmune a exploits de día cero.

La adopción de ERC-7281 hace que la evaluación de riesgos sea más dinámica. Los proyectos todavía tienen que completar la debida diligencia en los proveedores de puentes para elegir propiedades de limitación de tasa apropiadas; sin embargo, los plazos de evaluación de riesgos pueden reducirse para reflejar que los protocolos ya no se encuentran en una posición de todo o nada. En lugar de pasar meses analizando varios puentes para elegir una opción, un proyecto puede pasar la mitad del tiempo eligiendo múltiples proveedores de puentes inicialmente y estableciendo límites de acuñación variables basados en una evaluación de seguridad. El emisor del token puede luego llevar a cabo revisiones de seguridad para determinar si aumentar o disminuir los límites de acuñación para socios de puentes seleccionados o retirar los derechos de acuñación de un puente (por ejemplo, en respuesta a un hackeo o divulgación de vulnerabilidad).

ERC-7281 también reduce la barrera para proyectos que desean optar por avances de vanguardia en seguridad de puentes pero dudan en adoptar una tecnología en su totalidad hasta que la tecnología haya sido probada y evaluada rigurosamente por la comunidad (es decir, el dilema del innovador). Supongamos que un proveedor de puentes propone una nueva infraestructura que, según informes, mejora sustancialmente las garantías de seguridad. En ese caso, un protocolo puede “probar las aguas” asignando derechos de acuñación limitados al puente e incrementando progresivamente el límite de acuñación del puente a medida que la confianza en el diseño del sistema propuesto aumenta.

Al igual que eliminar las preocupaciones relacionadas con la liquidez, eliminar la necesidad de que un protocolo confíe en la pila tecnológica de un puente al 100% antes de asignar los derechos de acuñación crea una competencia equitativa entre los nuevos participantes y los antiguos jugadores: los viejos jugadores tienen el incentivo de iterar en mejores enfoques de seguridad, ya que los emisores de tokens ahora tienen la flexibilidad de retirar los derechos de acuñación y reasignarlos a un proyecto más pequeño solo porque este último ha demostrado un mayor compromiso con la seguridad y la descentralización. Esto también elimina otro factor de riesgo para los protocolos que trabajan con puentes de terceros: el riesgo de que un proveedor de puentes seleccionado deje de innovar en seguridad a pesar del rápido ritmo al que se revelan y descubren las fallas y problemas en la seguridad de los puentes porque sabe que el emisor del token no puede aplicar acciones punitivas (por ejemplo, migrar a otro proveedor de puentes) debido a la dificultad de ejecutar dichas actividades.

Mejorando la composabilidad entre ecosistemas

Hoy en día, es difícil crear flujos de trabajo de aplicaciones complicados que requieran enrutar tokens a través de cualquier número de cadenas debido a los precios impredecibles de los puentes basados en liquidez. Por ejemplo, un agregador de puentes que conecta Ethereum → Linea → Base tiene dos opciones:

1. Establezca un parámetro de tolerancia de deslizamiento y una ejecución de precios del enrutamiento entre cadenas en función de la cantidad mínima de tokens que recibirá un usuario en cada cadena (dependiendo de la cantidad de liquidez disponible cuando el mensaje de puente llegue a cada capa).
2. No establezca un parámetro de tolerancia al deslizamiento; en su lugar, cree lógica para obtener liquidez en cadena (por ejemplo, a través de DEXes) si la cantidad de tokens recibidos en una o más cadenas es inferior a la cantidad esperada.

En comparación, los agregadores de puentes pueden saber de antemano cuántos tokens deberían esperar en cada dominio involucrado en una transacción de cadena cruzada mediante la comprobación de mintingLimit y burningLimit para los puentes permitidos para emitir un token en particular. Es cierto que un puente puede alcanzar el maxLimit entre el momento de la transmisión de la transacción y la llegada de la transacción a un dominio, lo que significa que el usuario no puede recibir tokens canónicos en el destino.

Sin embargo, ERC-7281 sigue siendo una mejora en este sentido por las siguientes razones:

1. Si un operador de puente alcanza el límite de acuñación mientras una transacción está en curso, la transacción de puente se retiene y se vuelve a intentar más tarde cuando los parámetros de límite de tasa se ajusten. Los usuarios no reciben una representación envuelta propietaria del token canónico, a diferencia de los puentes de liquidez actuales.
2. Los agregadores de puentes tienen más previsibilidad en cuanto a cuándo se ejecutará una transacción puente y la cantidad de tokens que se pueden esperar. Dado que mintingLimit y burningLimit están configurados para usar bloques como medida de tiempo (como se muestra en la sección sobre parámetros de limitación de velocidad), es fácil calcular cuándo un puente comenzará a acuñar y quemar tokens nuevamente; por el contrario, predecir cuándo aumentará la liquidez en un puente es el equivalente a jugar a la ruleta rusa.

Los cambios impredecibles en la liquidez también significan imprevisibilidad en la fijación de precios de las transacciones de puente reintentadas. Supongamos que un agregador de puentes (u otra aplicación) coloca una cotización para un intercambio entre cadenas basado en el precio actual de un par de tokens en el pool de liquidez de un puente (este precio se basa en la liquidez total del pool). Sin embargo, la transacción no puede ejecutarse debido a una disminución brusca en la liquidez del pool. Supongamos que el intercambio se mantiene y se vuelve a intentar más tarde. En ese caso, el desarrollador de la aplicación no puede saber si la cotización anterior sigue siendo precisa o si la liquidez alcanzará los mismos niveles que cuando el usuario envió la transacción por primera vez.

Dado que la conexión de tokens xERC-20 no está sujeta a movimientos de liquidez, los usuarios pueden estar seguros de que las transacciones entre cadenas no incurrirán en deslizamientos, incluso si no se ejecutan de inmediato.

Los agregadores de puentes no son los únicos que se benefician de esta mejora en la composabilidad; cualquier aplicación cross-chain puede aprovechar la fungibilidad de los tokens xERC-20 para crear aplicaciones más emocionantes. Esto es más difícil hoy en día debido a los problemas en torno a la dependencia del camino: supongamos que un desarrollador desea bridgear ETH desde Ethereum, abrir una posición de préstamo en un DEX de Arbitrum y usar las ganancias para comprar un NFT en Optimism antes de regresar a Ethereum. Aquí, el desarrollador debe asegurarse de integrarse con proveedores de puentes en esas cadenas, ya que no se pueden intercambiar fácilmente versiones propietarias, lo cual no es el caso una vez que los tokens bridged de un proyecto son fungibles después de adoptar xERC-20.

Este flujo de trabajo es similar a los puentes emisores de tokens descritos anteriormente. Tomemos como ejemplo Circle CCTP:

El protocolo de transferencia entre cadenas de Circle permite a los usuarios tener una versión unificada y canónica de su token USDC sin quedar atrapados en el ecosistema de sus cadenas. Todas las transferencias entre cadenas se procesan a través de su protocolo utilizando el esquema burn-and-mint.

Sin embargo, mientras que CCTP es un protocolo centralizado, ya que los operadores de Circle son las únicas entidades que están autorizadas a quemar y acuñar sus tokens USDC, xERC-20 liquida el riesgo de confianza al permitir que múltiples entidades con diversos mecanismos de seguridad operen transferencias entre cadenas.

Apoyando la visión de Ethereum de un futuro multicadena centrado en el rollup

ERC-7281 puede acelerar la hoja de ruta centrada en la acumulación de Ethereum al brindar a los proyectos la confianza para implementar tokens en nuevas L2 EVM que pueden carecer de los sólidos perfiles de seguridad de las cadenas L2 establecidas. Por ejemplo, el puente canónico de un rollup de etapa 0 es menos seguro ya que Ethereum L1 no garantiza la seguridad del puente. Un proyecto de token puede desplegarse lentamente en una cadena de este tipo otorgando derechos de acuñación limitados al puente canónico y aumentando el límite de acuñación una vez que el rollup avanza a la etapa 1.

Este proceso puede continuar hasta que la L2 alcance la etapa 2 (la etapa más alta de descentralización y seguridad para un acumulativo). Un mecanismo mediante el cual los protocolos pueden desplegarse en cadenas recién lanzadas de forma minimizada el riesgo beneficia al ecosistema de Ethereum al facilitar que los nuevos L2 arranquen la liquidez y las aplicaciones de los tokens, al tiempo que fomenta una mayor innovación dentro del espacio de diseño de rollups.

Posibles inconvenientes de implementar ERC-7281

Aumento de los gastos generales para los equipos de gestión de proyectos de DAO

Si bien ERC-7281 es muy atractivo para los protocolos, las DAO pueden dudar en adoptar tokens xERC-20 debido a la importante sobrecarga operativa en la que deben incurrir los equipos de proyectos de DAO para administrar tokens xERC-20 en varias implementaciones.

La de Gerard Persoon Administre tokens puenteados en una gran cantidad de cadenasincluye una lista no exhaustiva de tareas únicas y recurrentes que el protocolo debe llevar a cabo después de migrar de ERC-20 a xERC-20:

Esa es una lista muy larga de tareas

Una solución propuesta es que las DAO externalicen algunas de estas tareas administrativas relacionadas con la gestión de tokens xERC-20 entre cadenas a servicios de terceros, pero esto simplemente intercambia un compromiso (costos de recursos humanos) por otro (costos de contratar servicios).

Supongamos que un protocolo anteriormente gestionaba tokens cross-chain con infraestructura interna (por ejemplo, desplegando un contrato de token separado por cadena y controlando la emisión y quema). En ese caso, ERC-7281 no parece un cambio radical. Sin embargo, los proyectos acostumbrados a externalizar la gestión de la infraestructura principal de puente a equipos de desarrollo de puentes encontrarán preocupante la carga de trabajo adicional.

Por ejemplo Un miembro central del equipo de Lido esbozó(en respuesta a una propuesta para que Lido implemente wstETH como un token xERC-20 en todas las implementaciones) las responsabilidades actuales del equipo de PM relacionadas con la infraestructura de interoperabilidad y contrastó el conjunto con el conjunto de responsabilidades que los mismos miembros del equipo tendrían que asumir si la DAO de Lido votara para que wstETH en todos los dominios migrara a una versión xERC-20.

Como muestra la conversación anterior, la gestión de tokens xERC-20 impone un aumento no despreciable en la sobrecarga administrativa para los protocolos y los miembros de la comunidad. Por ejemplo, los límites de los puentes requieren un seguimiento y una evaluación activos de la seguridad de los puentes para informar de los ajustes de los límites de acuñación, y las decisiones sobre los límites de los puentes (o la retirada/cesión de los derechos de acuñación) pueden estar sujetas a una votación de la DAO (si es necesario tomar tales decisiones con frecuencia, los miembros de la DAO pueden sufrir fatiga de los votantes).

Sin embargo, esto no debe interpretarse como un juicio de valor sobre ERC-7281. Cada proyecto tendrá diferentes perfiles de riesgo, objetivos a largo plazo y recursos, y estos factores determinan colectivamente si el beneficio a largo plazo de adoptar ERC-7281 supera los costos a corto plazo y continuos de hacerlo.

Por ejemplo, los proyectos más pequeños pueden tener más dificultades para gestionar los gastos generales de la emisión de tokens xERC-20 y optar por un servicio de puente de tokens multicadena gestionado como el ITS (Interchain Token Service) de Axelar o el NTT (Native Token Transfers) de Wormhole. Los proyectos más establecidos pueden tener los recursos para administrar los costos administrativos y operativos de la emisión de un token xERC-20 y pueden considerar que el control que brinda ERC-7281 vale la pena la sobrecarga adicional de administrar tokens entre cadenas.

Dificultades en torno a la migración de tokens existentes al estándar xERC-20

Para proyectos que no tienen una interfaz de creación/quema, o no pueden actualizar contratos de tokens para usar IERC20 a través de la herencia, y ya tienen representaciones canónicas de tokens nativos circulando en cadenas no nativas, migrar a tokens xERC-20 es un proceso largo que requiere una gran cantidad de coordinación e implica una compleja red de participantes, que van desde los titulares de tokens, intercambios (DEXes y CEXes), puentes asociados y aplicaciones integradas con el token ERC-20 heredado. Incluso con esta parte resuelta, los protocolos aún soportan el costo de desbloquear ERC-20s en xERC-20s para completar el proceso de migración.

Como se explicó en la discusión de la especificación ERC-7281, los tokens existentes deberán estar bloqueados en la caja de seguridad para acuñar xERC-20 envueltos para los usuarios. La extinción del ERC-20 heredado ocurre poco después e implica otro proceso prolongado de comunicación compartida con la comunidad en torno al cronograma para congelar la acuñación de nuevos tokens ERC-20 (heredados). Una vez más, esto puede valer la pena desde la perspectiva de un protocolo, aunque los beneficios también pueden ser insuficientes para justificar los costos de coordinar una migración de todo el ecosistema a la representación compatible con xERC20 del token de un protocolo.

Superficie de riesgo mayor para la gobernanza de DAO

La gestión de tokens xERC-20 en varios dominios con ERC-7281 requiere una gobernanza activa por parte de la DAO que supervisa el protocolo. Esto implica establecer parámetros como los límites de acuñación, actualizar el contrato de la caja de seguridad y pausar la acuñación o quema de tokens. Estas decisiones son sensibles a la seguridad y deben ser regidas por la DAO para evitar la responsabilidad de las decisiones de la sala de juntas cerrada.

ERC-7281 tiene como objetivo dar a los protocolos el control sobre estas decisiones en lugar de puentes de terceros. Esto tiene sentido, ya que las DAO ya gestionan tokens en sus cadenas nativas, por lo que ampliar su gobernanza a los tokens de otras cadenas es razonable para los protocolos y las comunidades que buscan este control. Sin embargo, es posible que algunos protocolos no quieran este control adicional de la DAO debido a preocupaciones sobre la gobernanza y la estabilidad.

Por ejemplo, proyectos de alto perfil como Lido enfrentan escrutinio sobre problemas de gobernanza. Agregar control sobre la gestión de tokens aumenta el riesgo de una toma de control de la gobernanza. Un ataque de gobernanza podría tener efectos generalizados si un proyecto consolida todos los tokens ERC-20 en un Buzón de Bloqueo y el DAO lo gobierna. Un atacante podría tomar el control del Buzón de Bloqueo e introducir un proveedor de puente malicioso sin límites de acuñación, haciendo que los tokens xERC-20 en otras cadenas no tengan valor.

Este escenario tiene paralelismos con la explotación de Multichain, donde una vulnerabilidad en la infraestructura de firma de computación multiparte (MPC) permitió a los hackers comprometer las direcciones principales de Multichain que custodiaban tokens nativos en Ethereum y Dogecoin; estos tokens respaldaban tokens acuñados en cadenas no nativas como Fantom y Moonriver, lo que creó un efecto dominó que resultó en proyectos en otros lugares sufriendo pérdidas como resultado del ataque a los contratos inteligentes de Multichain en Ethereum y Dogecoin.

Incompatibilidad con protocolos máximamente descentralizados

ERC-7281 se ajusta al propósito cuando el token es emitido por un protocolo con gobernanza de tokens o una entidad centralizada (por ejemplo, USDC de Circle o el CZKC stablecoin). Sin embargo, no es tan valioso si el protocolo está máximamente descentralizado y carece de gobernanza formal: la stablecoin LUSD de Liquity es un ejemplo de un token que sería difícil de hacer compatible con el estándar xERC-20.

El token xERC-20 requiere que una entidad decida sobre parámetros específicos como los límites de acuñación y quema y tome decisiones sobre si incluir o no en la lista blanca a ciertos proveedores de puentes. Esto implica la necesidad de una gobernanza continua para la existencia del token xERC-20. Para proyectos que deseen descentralizar componentes críticos del protocolo, como el contrato de tokens del DAO, con el tiempo, esto puede causar problemas y complicar los planes de descentralización.

Riesgo mayor de exploits que afectan los componentes principales (contrato Lockbox y proveedores de puente)

Ya mencionamos cómo funciona la dependencia de la ruta y por qué ayuda a proporcionar garantías de que un exploit que afecta a la cadena A no afectará a la cadena B, o que un exploit que involucra al puente A en la cadena A no afectará al puente B en la cadena B. ERC-7281 elimina la dependencia de la ruta, lo que tiene beneficios, pero también introduce una compensación en torno a la seguridad:

La liquidez máxima disponible en un puente ya no representa un límite superior en el impacto potencial de una explotación de puente en el emisor de tokens, ya que los tokens emitidos por diferentes proveedores de puentes son fungibles entre dominios. Los autores de ERC-7281 proponen elegir un límite de tasa para los proveedores de puentes basado en la cantidad que un emisor de tokens puede gastar para compensar las pérdidas por la emisión fraudulenta; aun así, un límite de tasa seleccionado puede haber sido demasiado conservador en retrospectiva.

Si un puente con un límite alto se ve comprometido, los efectos pueden ser pronunciados, incluso para los usuarios de otros puentes que acuñan el mismo token. Los protocolos pueden reducir el riesgo distribuyendo los derechos de acuñación en un amplio número de puentes (de modo que un proveedor de puentes no tenga un número descomunal de tokens que pueda acuñar en comparación con otros puentes), pero tratar de cubrir el riesgo de esta manera puede aumentar la ineficiencia, ya que cada puente requerirá una evaluación independiente del equipo de la DAO y la coordinación con más puentes aumenta la sobrecarga administrativa que mencionamos anteriormente.

El contrato Lockbox gobernado por un DAO podría introducir efectos de contagio adverso en caso de un ataque a la gobernanza. Pero incluso con una gobernanza segura de DAO, un error en los contratos nativos/no nativos de Lockbox en la cadena de origen del token puede causar igual cantidad de problemas (Sifu es ahora el propietario del contrato Lockbox para un proyecto, y los fondos ya no están SAFU). En comparación, este problema se reduce en el estado actual, ya que los contratos de bóveda (el equivalente del contrato Lockbox del proveedor de puente) solo contienen tokens puente a través del servicio de puente correspondiente. Por lo tanto, un error en el contrato de bóveda para un proveedor solo afecta a los usuarios que depositaron tokens con ese puente.

Sobrecarga para las integraciones de ecosistemas

El trabajo administrativo adicional con ERC-7281 también afecta a los desarrolladores de aplicaciones y proveedores de servicios que utilizan el token xERC-20 de un proyecto. Los agregadores de puentes deben realizar un seguimiento de las asignaciones entre los tokens xERC-20 y sus contratos de caja de seguridad correspondientes para evitar problemas como tokens de spam y ataques de suplantación de identidad. Si bien un registro de estas asignaciones podría ayudar, la configuración de un registro de este tipo es un desafío sin correr el riesgo de la centralización o exponer a los adoptantes de xERC-20 a amenazas.

El riesgo proviene de los atacantes que pueden agregar contratos maliciosos al registro de tokens y engañar a los usuarios y desarrolladores para que envíen tokens a la dirección incorrecta. Esto podría conducir al robo de tokens en las redes L2 y L1. Los exchanges se enfrentan a retos similares, ya que los tokens falsificados podrían causar problemas graves, como el comportamiento inesperado de los tokens, que difiere de los tokens canónicos examinados.

Conclusión

ERC-7281 presenta una solución convincente a los problemas de los tokens puentes no fungibles y ofrece características que mejoran la experiencia del usuario, la descentralización, la seguridad y la flexibilidad en los diseños de puentes de tokens. Algunos de estos problemas afectan directamente a la viabilidad de la hoja de ruta centrada en el rollup, lo que convierte al xERC-20 en una infraestructura crítica estándar para el ecosistema L2 de Ethereum.

Varios actores clave en el espacio de puentes, incluidos Hyperlane, Omni, Sygma, Protocolo de Enrutador y Everclear, se han comprometido a adoptar ERC-7281, lo que indica una tracción significativa para la propuesta. Incluso emisores de tokens establecidos (que tienen mecanismos de trabajo para la transferencia de tokens), como Circle, han mostrado interés en ERC-7281 para abordar los desafíos planteados por los tokens no aprobados que afectan a usuarios y desarrolladores.

ERC-7281 aborda estos problemas al tiempo que mitiga muchas compensaciones asociadas con enfoques anteriores para acuñar tokens canónicos en dominios remotos. Proporciona un arranque sin liquidez, a diferencia de los puentes consagrados, no requiere infraestructura personalizada como puentes emisores de tokens y evita la dependencia de un proveedor al permitir la acuñación de tokens canónicos de varios puentes por parte de proveedores de puentes aprobados.

Para aquellos interesados en seguir la discusión sobre ERC-7281 o desarrolladores que buscan integrar xERC-20, La Hermandad de los Magos de Ethereum y el sitio web xERC-20son excelentes recursos. La comunidad también ha construido unlanzadera xERC-20 para agregar herramientas para crear, monitorear y administrar tokens xERC-20, una herramienta valiosa para los constructores que buscan implementar un token xERC-20 por primera vez o migrar un token existente al estándar de tokens xERC-20.

Renuncia:

1. Este artículo es una reimpresión de [2077 Investigación]. Todos los derechos de autor pertenecen al autor original [Investigación 2077]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learn equipo, y lo manejarán con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. El equipo de Gate Learn hace traducciones del artículo a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.