Introducción

Los maxis modulares dicen que el futuro de las criptomonedas es un millón (o más) de dominios interconectados y usuarios que saltan entre blockchains como Alicia paseando por el País de las Maravillas. ¿Por qué quedarse con una cadena si puedes acceder a tecnología de vanguardia, aplicaciones novedosas, altas recompensas por participar en staking/provisión de liquidez, alto rendimiento y comisiones de transacción ultrabajas en otras blockchains?

Pero moverse entre blockchains es mucho más complicado que el viaje de Alicia por el País de las Maravillas, principalmente debido a las limitaciones inherentes en los enfoques actuales de interoperabilidad de blockchain (por ejemplo, puentes inter-bloque). En particular, los puentes inter-bloque de hoy en día son inseguros ($2.5B+ perdidos en hacks de puentes), lentos, costosos o limitados en funcionalidad, o muestran una combinación de propiedades de la lista.

Otros problemas que aquejan a la industria de puentes son más sutiles pero aún suficientes para convertir el sueño de un ecosistema multi-cadena en una pesadilla para usuarios y desarrolladores — un ejemplo de esto es cómo los tokens fungibles (como los ERC-20) se vuelven no fungibles cuando se cruzan a diferentes cadenas a través de varios protocolos de cross-chain, afectando sus características como activo transferible. En este artículo, exploraremos una solución que busca preservar la fungibilidad de los tokens a través de las cadenas, independientemente de dónde exista el contrato de origen del token: ERC-7281: Tokens Sovranos con Puentes.

ERC-7281 extiende ERC-20, el estándar de facto para crear tokens fungibles en Ethereum, para permitir la creación y eliminación de representaciones canónicas de tokens ERC-20 en dominios remotos por múltiples puentes aprobados por los emisores de tokens. Esto asegura que los usuarios que atraviesan un token ERC-20 reciben versiones fungibles del token en el destino (es decir, dos tokens pueden intercambiarse 1:1), incluso cuando los tokens se envían a través de diferentes rutas/puentes. Es importante destacar que los protocolos que adoptan ERC-7281 mantienen el control de los tokens atravesados (a diferencia del statu quo donde el puente controla un token atravesado) y pueden limitar la creación de tokens para reducir la exposición en caso de fallo del puente.

Tomemos USDC como ejemplo de infungibilidad entre tokens ERC-20 teóricamente idénticos en diferentes cadenas. En Redes de capa 2 (L2) de Ethereum, como Arbitrum, Base, Optimism, es común utilizar el puente canónico para mover tokens ERC-20 populares desde Ethereum L1 a estas cadenas. Estas versiones de tokens L2 de origen L1 se llaman comúnmente simplemente 'tokens puente [insertar nombre del token]'.

En el caso de USDC, los símbolos comunes son USDC.e, USDC.b, y así sucesivamente. Con el tiempo, Circle expande sus implementaciones de USDC a otras cadenas, incluyendo L2s, donde USDC ya está en vivo a través del puente canónico. Aunque estos dos tokens son acuñados por la misma entidad y tienen el mismo precio, son técnicamente diferentes, tokens infungibles, por lo tanto no son “interoperables”—mientras que el USDC nativo puede ser cruzado a través del puente CCTP de Circle, el USDC cruzado solo puede ser cruzado de vuelta al L1 a través del puente canónico.

ERC-7281 soluciona este problema introduciendo una extensión ERC-20 donde los desplegadores del token pueden asignar y parametrizar diferentes fuentes de puente para él. En el ejemplo anterior, Circle podría desplegar un token USDC universal en todos los L2s, donde los puentes canónicos (por ejemplo, Circle Mint, Circle CCTP, y otros puentes aprobados) están asignados como capaces de acuñar los tokens de acuerdo a su lógica. Para minimizar los riesgos de que los acuñadores sean hackeados, el desplegador puede limitar cuántos tokens puede acuñar y quemar cada acuñador en un período de tiempo específico, con puentes más confiables, como el L2 canónico, teniendo límites más altos, y puentes con consenso centralizado teniendo límites más bajos.

Si bien ERC-7281 no es el primer intento de crear tokens fungibles cross-chain, soluciona problemas asociados con propuestas anteriores, como el bloqueo del proveedor, la pérdida de soberanía para los emisores de tokens, los altos costos de arrancar liquidez para tokens puente, los gastos generales de infraestructura y la mayor exposición a fallos en el puente.

Este informe de dos partes examinará la justificación para introducir un estándar de token soberano y puenteado y proporcionará una visión general exhaustiva de la especificación ERC-7281 (también conocida como xERC-20). También discutiremos los beneficios positivos y posibles desventajas de implementar ERC-7281 para usuarios, desarrolladores, proveedores de infraestructura y otros actores en el ecosistema Ethereum.

Un repaso sobre puentes de blockchain

Antes de adentrarnos en el problema de los tokens cruzados no fungibles, es útil entender por qué existen los tokens cruzados en primer lugar. Esto, a su vez, requiere comprender la motivación y el funcionamiento de los puentes blockchain, ya que los operadores de puentes son quienes se encargan de crear versiones de tokens cruzados.

Un puente es un mecanismo para transferir información entre blockchains. Además de la información puramente monetaria, los puentes pueden transmitir cualquier información útil, como tasas de tokens y estado de contratos inteligentes en otras cadenas. Sin embargo, transferir activos (tokens) de una cadena a otra es el caso de uso más común para los usuarios que interactúan con un puente en la actualidad.

Los enfoques para facilitar las transferencias de activos entre cadenas varían, pero los flujos de trabajo de puente de tokens generalmente siguen uno de tres patrones de alto nivel:

Bridges de bloqueo y acuñación

• Un usuario desea conectar un token desde su cadena nativa o "hogar" (donde se emitió inicialmente) a otra cadena. Las dos blockchains no son interoperables, ya que cada cadena implementa arquitecturas y diseños de protocolo diferentes, lo que impide al usuario transferir tokens directamente desde una dirección de billetera en la cadena A a una dirección de billetera en la cadena B.
• El operador del puente custodia los tokens depositados por el usuario en la cadena de origen en un contrato inteligente y crea una representación "envuelta" del token nativo a través de un contrato de token desplegado en la cadena de destino.
• Cuando el usuario desea hacer un puente en la dirección inversa (cadena de destino → cadena de origen), devuelven los tokens envueltos al puente en la cadena de destino, que verifica esto según la lógica en el puente (por ejemplo, pruebas ZK o un quórum externo) y libera los tokens originales de la garantía en la cadena de origen.

Quemar y crear puentes de interoperabilidad

• En lugar de bloquear tokens en custodia, este enfoque quema (destruye) los tokens en la cadena de origen;
• Luego, el puente crea una cantidad equivalente en la cadena de destino;
• Para el viaje de regreso, los tokens puente se queman en la cadena de destino antes de que se emitan nuevos tokens en la cadena de origen;
• Esto mantiene el suministro total de tokens al permitir transferencias entre cadenas.

Intercambios atómicos

• Este enfoque intercambia directamente activos en la cadena de origen por activos en la cadena de destino con otra parte.
• Los intercambios atómicos funcionan mediante el bloqueo mutuo de fondos con el mismo valor secreto para desbloquearlos, lo que significa que si en cualquier lado se revela el secreto, también se puede revelar en el otro. Esto le da a los intercambios la propiedad de atomicidad.
• Atomicidad significa que el intercambio se completa por completo (en ambos lados) o no se completa en absoluto, evitando el fraude o transferencias parciales/fallidas.

El primer enfoque (bloquear y acuñar) es actualmente el más común. La equivalencia en valor entre un token nativo y su representación envuelta correspondiente acuñada por un puente es lo que permite a los usuarios "transferir" activos de cadena cruzada y usar un token en una cadena separada de donde se emitió inicialmente.

Sin embargo, nuevos diseños, como el puente basado en intenciones, se han vuelto bastante populares. Las 'intenciones' permiten a los usuarios expresar los resultados deseados para las transacciones ('intercambiar 100 USDC por 100 DAI') en lugar de describir pasos específicos para lograr los resultados. Las intenciones han surgido como un desbloqueo UX poderoso, ya que simplifican en gran medida la experiencia en la cadena para las personas y facilitan el uso de las criptomonedas, especialmente cuando se combinan con soluciones de abstracción de cadena.

Intenciones de cross-chainpermitir a los usuarios transferir tokens entre cadenas sin preocuparse por la complejidad subyacente de los puentes. En los puentes basados en intenciones, los usuarios depositan fondos en la cadena de origen y especifican su resultado deseado en la cadena de destino (su 'intención'). Los operadores especializados llamados 'fillers' o 'solvers' pueden cumplir esta intención enviando los tokens solicitados al usuario en la cadena de destino por adelantado. Los operadores luego demuestran que ocurrió la transferencia para reclamar los fondos bloqueados en la cadena de origen como reembolso.

Algunos puentes basados en la intención aprovechan mecanismos de bloqueo y acuñación en el fondo. En este caso, el puente acuña tokens envueltos que se envían ya sea al llenador que cumplió con la intención del usuario, o directamente al usuario si ningún llenador intervino. Si bien los puentes basados en la intención agregan una capa adicional de eficiencia a través de su red de solucionadores, todavía dependen fundamentalmente de los mismos principios que los puentes tradicionales de bloqueo y acuñación.

Podemos pensar en cada token envuelto, ya sea creado a través de un puente tradicional o basado en intenciones, como un IOU del operador del puente que promete liberar una cantidad del token subyacente del contrato de depósito en garantía. El valor de estos activos envueltos se correlaciona directamente con la capacidad (percibida) del operador del puente para procesar solicitudes de los titulares para retirar tokens nativos depositados en el chain de origen del token.

El puente autorizado para bloquear los tokens subyacentes en la cadena de origen y crear sus representaciones envueltas en la cadena de destino garantiza que el suministro total del token se mantenga constante. Por una unidad del token subyacente, se crea exactamente una unidad del token envuelto correspondiente y viceversa. Si una aplicación acepta un token envuelto como medio de intercambio o utiliza activos envueltos como moneda, los desarrolladores y usuarios de la aplicación confían en el proveedor del puente para asegurar los activos "reales" que respaldan el token envuelto.

¿Por qué necesitamos puentes?

La capacidad de realizar transacciones con una versión sintética de un activo en una cadena remota, habilitada por puentes que crean representaciones del activo, es una característica poderosa y permite a los desarrolladores y usuarios aprovechar los beneficios de la interoperabilidad entre cadenas. Algunos de estos beneficios incluyen acceso a más liquidez, exposición a nuevos usuarios y flexibilidad para los usuarios (que pueden interactuar con aplicaciones favoritas de diferentes cadenas sin fricciones).

Para comprender mejor cómo funciona esto en la práctica y por qué es importante tanto para los desarrolladores como para los usuarios, examinemos un ejemplo concreto utilizando un intercambio descentralizado ficticio llamado BobDEX. Este ejemplo demostrará cómo los tokens envueltos permiten la expansión cross-chain mientras destacan tanto los beneficios como las posibles complicaciones que pueden surgir:

BobDEX es un intercambio de creador de mercado automatizado (AMM) que Bob creó en Ethereum para permitir intercambios sin confianza entre diferentes activos. BobDEX tiene un token nativo, $BOB, que también funciona como token de gobernanza y token de recompensa LP. En este último caso, BobDEX emite tokens BOB a los proveedores de liquidez (LP), otorgando a los usuarios que proporcionan liquidez a un pool un porcentaje de las tarifas pagadas por los usuarios de DEX que intercambian activos depositados en el pool.

La cuota de mercado de BobDEX ha crecido significativamente, pero las limitaciones de Ethereum L1 dificultan un mayor crecimiento. Por ejemplo, algunos usuarios no quieren usar BobDEX en Ethereum debido a las altas comisiones de gas y los retrasos en las transacciones; de manera similar, otros usuarios desean tener exposición al precio de los tokens $BOB sin tener que poseer tokens nativos $BOB en Ethereum.

Para resolver el problema, Bob implementa una versión de BobDEX en Arbitrum (un rollup de capa 2 de baja comisión y alta velocidad) e implementa una versión envuelta del token BOB (wBOB) en L2 a través del puente Arbitrum-Ethereum. BobDEX en Arbitrum es idéntico a BobDEX en Ethereum, excepto que utiliza wBOB en lugar de tokens BOB nativos para recompensas de LP y gobernanza.

La diferencia en los tokens de aplicación (BOB envuelto vs. BOB nativo) no hace ninguna diferencia desde la perspectiva de los usuarios (por ejemplo, proveedores de liquidez) que interactúan con BobDEX en Arbitrum. Dado que los tokens wBOB están respaldados por tokens BOB reales mantenidos en el puente Arbitrum-Ethereum, los titulares de tokens wBOB pueden intercambiar fácilmente los tokens nativos de BOB ERC-20 en Ethereum al interactuar con el contrato puente.

La situación es beneficiosa para Bob y los usuarios:

1. Bob puede atraer a más usuarios, especialmente a usuarios que deseen tarifas de gas bajas y confirmaciones de transacciones rápidas al negociar en BobDEX
2. Los LP pueden ganar recompensas al proporcionar liquidez a BobDEX sin lidiar con los altos costos de gas y largos tiempos de confirmación de Ethereum
3. Los Hodlers pueden comprar tokens wBOB en el mercado para obtener beneficios de los cambios en el precio de los tokens BOB sin interactuar con el contrato BOB ERC-20 en Ethereum

Los beneficios del puente también se extienden a mejorar la innovación componible y desbloquear nuevos casos de uso que aprovechan la liquidez de un token puente. Por ejemplo, Alice puede crear un protocolo de préstamos llamado AliceLend en Arbitrum que acepta wBOB como garantía de los prestatarios para expandir la utilidad de wBOB y crear un nuevo mercado parapréstamo y préstamo.

Los prestamistas que proporcionan liquidez a AliceLend tienen la certeza de recibir depósitos: si un usuario incumple un préstamo, AliceLend subasta automáticamente los tokens wBOB depositados como garantía para reembolsar a los prestamistas. En este caso, los compradores de la garantía wBOB liquidada asumen el papel de LP en BobDEX y tienen la misma garantía de que los tokens wBOB se pueden intercambiar 1:1 por los tokens BOB originales.

El puente entre cadenas en su forma actual ha proporcionado una solución viable para garantizar interoperabilidad entre (anteriormente aislados) L2s de Ethereumy facilitar nuevas aplicaciones (por ejemplo, préstamos entre cadenas y DEXes entre cadenas). Pero el ecosistema de puenteo actualmente se enfrenta a limitaciones que obstaculizan un mayor crecimiento, como la no fungibilidad de los tokens entre cadenas; exploraremos este problema en detalle posteriormente.

¿Por qué los tokens puente se vuelven no fungibles?

El flujo de trabajo de puenteo de bloqueo y acuñación descrito anteriormente parece simple en teoría, pero en realidad requiere mucho esfuerzo de ingeniería y diseño de mecanismos para funcionar correctamente.

El primer desafío consiste en garantizar que las versiones envueltas de un token puenteadas siempre estén respaldadas por tokens nativos bloqueados en la cadena de origen. Si un atacante crea representaciones de un token en una cadena remota sin depositar tokens nativos en la cadena de origen, puede hacer que el puente sea insolvente al intercambiar tokens envueltos (falsamente creados) por tokens nativos en la cadena de origen y evitar que los usuarios legítimos, que depositaron en el contrato del puente antes de crear tokens envueltos, retiren sus depósitos.

El segundo desafío es más sutil y se deriva de la naturaleza de los tokens cruzados: dos representaciones de un token acuñado por proveedores de puentes en la misma cadena remota no se pueden intercambiar 1:1 por otro. Podemos usar otro ejemplo de dos usuarios que intentan intercambiar tokens cruzados a través de rutas diferentes para ilustrar este aspecto del problema asociado con mover tokens entre cadenas:

• Alice conecta USDC desde Ethereum a Arbitrum a través del puente canónico de Arbitrum y recibe 200 USDC.e en Arbitrum, mientras que Bob conecta USDC a Arbitrum a través de Axelar y recibe 200 axlUSDC en Arbitrum. Alice y Bob llegan a un acuerdo para que Alice envíe 200 USDC a Bob (a cambio de 200 USDT) para que Bob pueda retirar 400 USDC a Ethereum.
• Bob intenta retirar 400 USDC a través de axlUSDC y solo recibe 200 USDC, junto con un mensaje que explica que el puente solo tiene 200 USDC para darle a Bob. Bob está confundido ya que se supone que los tokens ERC-20 envueltos son "fungibles" y no deberían mostrar disparidades que impidan a cualquier persona intercambiar tokens ERC-20 1:1 en cualquier aplicación.
• Bob aprende una dura lección sobre el puente cruzado: “token ERC-20 fungible” no siempre significa “puedes intercambiar este token 1:1 con otros tokens ERC-20 en diferentes aplicaciones”. El intento de Bob de hacer negocios arriesgados con Alice, arriesgado ya que Alice puede que no devuelva los tokens, resulta espectacularmente mal.

Bob después de ser estafado en un intercambio

¿Por qué Bob no puede retirar 400 USDC si él y Alice recibieron versiones envueltas del mismo activo subyacente en la cadena de destino? Recordarás que mencionamos que los tokens emitidos en diferentes cadenas son incompatibles, por lo que la representación de un token nativo emitido en una cadena no nativa es un IOU del puente que promete devolver una cantidad de tokens nativos (dependiendo de cuanto quede) cuando el usuario desee volver al token de la cadena nativa.

El valor de cada token puenteado está así vinculado al proveedor del puente responsable de mantener los depósitos en la cadena de origen y emitir representaciones en la cadena de destino; el proveedor del puente de Bob solo puede pagarle a Bob 200 USDC, ya que es la cantidad que tiene fondos para cubrir de su depósito; los 200 USDC de Alice no pueden ser retirados a través del proveedor del puente de Bob, ya que nunca recibió el depósito ni emitió un IOU a Alice. Alice debe retirar sus USDC bloqueados de Arbitrum en Ethereum y pasar por el proveedor del puente de Bob antes de que Bob pueda acceder a los tokens restantes.

El dilema de Bob y Alice apunta a un problema con la conexión entre dominios donde múltiples representaciones no fungibles de un activo subyacente son creadas por proveedores de puentes en competencia. El otro problema con diferentes representaciones ERC-20 del mismo activo es que no se pueden intercambiar en un único pool de liquidez.

Usando el ejemplo anterior, si tenemos axlUSDC y USDC.e en la cadena y queremos intercambiarlos por ETH y viceversa, debemos desplegar dos pools de liquidez: ETH/axlUSDC y ETH/USDC.e. Esto lleva a un problema de 'fragmentación de liquidez', una situación en la que los pools de trading tienen menos liquidez de la que podrían tener porque hay múltiples pools que se adaptan esencialmente al mismo par de trading.

La solución es tener una única versión “canónica” de un token circulando en la cadena de destino para que Bob y Alice puedan intercambiar tokens sin que cada persona tenga que retirarse del puente en la cadena de origen. Tener un token canónico por cadena también beneficia a los desarrolladores, ya que los usuarios pueden moverse rápidamente entre ecosistemas sin lidiar con problemas de liquidez de tokens.

Entonces, ¿cómo implementamos versiones canónicas de un token en cada cadena en la que se espera que se utilice y se transfiera entre ellas? La siguiente sección explica algunos de los enfoques populares para crear tokens canónicos en múltiples cadenas.

Implementando tokens canónicos en diferentes cadenas

Crear un token canónico por cadena no es sencillo, y existen múltiples opciones con diferentes compensaciones y ventajas. Al crear un token canónico por cadena, generalmente necesitamos pensar en a quién confiar sobre la existencia de IOUs que respalden el valor de un token en particular. Supongamos que eres el creador de un token y deseas que sea utilizable y transferible en diferentes cadenas sin problemas de fungibilidad; tienes cuatro opciones:

1. Crear tokens canónicos a través de puentes canónicos de rollup o sidechain
2. Acuñar tokens canónicos a través de un proveedor de puente de terceros
3. Crear tokens canónicos a través de un puente de emisor de tokens
4. Emisión directa en múltiples cadenas con intercambios atómicos

Las tres primeras opciones se basan en varios mecanismos de puente para facilitar el movimiento de tokens entre cadenas. Sin embargo, como creador de tokens, también puede optar por omitir el puente por completo emitiendo el token de forma nativa en cada cadena compatible. Con este enfoque, en lugar de depender de tokens envueltos o de la infraestructura de puentes, se mantienen implementaciones de tokens separadas pero coordinadas entre cadenas, con intercambios atómicos que permiten el intercambio sin confianza entre cadenas.

Sin embargo, este enfoque requiere una infraestructura sofisticada para mantener la liquidez entre cadenas y facilitar los intercambios atómicos. La complejidad de gestionar múltiples implementaciones nativas ha limitado históricamente este enfoque a protocolos más grandes con recursos técnicos sustanciales.

1. Acuñar tokens canónicos a través de puentes rollup/sidechain canónicos

Si una cadena tiene un puente canónico (consagrado), puede asignar el derecho de acuñar representaciones del token de su protocolo para los usuarios que deseen hacer un puente desde la cadena nativa. Las transacciones dirigidas a través del puente canónico de la cadena (depósitos y retiros) suelen ser validadas por el conjunto de validadores de la cadena, lo que proporciona garantías más sólidas de que los depósitos en la cadena de origen respaldan de manera creíble todas las representaciones acuñadas.

Aunque el puente canónico está generando la representación canónica de un token, seguirán existiendo otras representaciones. Esto sucede simplemente porque los puentes canónicos a menudo tienen limitaciones que les impiden ofrecer a los usuarios la mejor experiencia. Por ejemplo, al realizar un puente desde Arbitrum/Optimism a Ethereum a través del puente canónico del rollup, se produce un retraso de siete días ya que las transacciones deben ser validadas por verificadores y posiblemente disputadas por un prueba de fraude, si es inválido, antes de la capa de liquidación del rollup (Ethereum) se liquida un lote de transacciones.

Los usuarios de Rollup que deseen salidas más rápidas deben utilizar otros proveedores de puentes que puedan asumir la propiedad de las salidas pendientes de rollup y proporcionar liquidez por adelantado en la cadena de destino deseada del usuario. Cuando dichos puentes utilizan el modelo tradicional de bloqueo y emisión, terminamos con múltiples representaciones envueltas de un token emitido por diferentes protocolos y nos enfrentamos a los mismos problemas descritos anteriormente.

Las sidechains con conjuntos de validadores independientes tienen una menor latencia, ya que las retiradas se ejecutan una vez que el protocolo de consenso de la sidechain confirma un bloque que contiene una transacción de retirada. El puente PoS de Polygon es un ejemplo de un puente canónico que conecta una sidechain con diferentes dominios (incluyendo rollups de Ethereum y la red principal de Ethereum).

Nota: Nos referimos a la cadena original de PoS de Polygon, no a la cadena de validium planificadaque utilizará Ethereum para liquidación. Polygon se convertirá en un L2 una vez que se complete el cambio de una sidechain asegurada por validadores externos a un validium asegurado por consenso de Ethereum.

Sin embargo, los puentes de sidechain también comparten una debilidad con los puentes canónicos de rollup: los usuarios solo pueden hacer puentes entre un par de cadenas conectadas. No pueden hacer puentes hacia otras blockchains utilizando el puente canónico. Por ejemplo, no puedes hacer un puente desde Arbitrum a Optimism hoy en día utilizando el puente de Arbitrum o hacer un puente desde Polygon a Avalanche a través del puente de PoS de Polygon.

1.1. Generar tokens canónicos utilizando puentes de liquidez

Depender de un puente nativo de rollup para mover tokens canónicos conlleva varios problemas, como una liquidez deficiente y retrasos en el movimiento de activos. Los protocolos trabajan en torno a este problema al colaborar con puentes de liquidez para facilitar retiros rápidos y puentes de baja latencia*.

Bajo este acuerdo, los puentes de liquidez aprobados (a) crean representaciones envueltas de un token de protocolo en la cadena de origen (b) intercambian tokens envueltos por la representación canónica en el destino a través de un pool de liquidez propiedad del protocolo.

La representación canónica del token en la cadena de destino suele ser la versión acuñada por el puente de la cadena lateral/rollup canónica, aunque existen excepciones (como veremos más adelante). Por ejemplo, la versión canónica de USDT en Optimism es opUSDT acuñada por el puente de Optimism.

Cada puente de liquidez funciona como un DEX con un Creador de Mercado Automatizado (AMM) para ejecutar intercambios entre pares de activos depositados en diferentes pools de liquidez. Para incentivar la provisión de liquidez, los pools de AMM comparten una parte de las comisiones de intercambio con los titulares que bloquean tokens canónicos en los contratos del pool.

Esto es similar al modelo de Uniswap; la única diferencia notable es que los pares de activos suelen ser la representación de puente de liquidez de un token frente a la representación canónica. Por ejemplo, un usuario que conecte USDT a Optimism a través de Hop tendrá que intercambiar hUSDT en Optimism a través del pool huSDT:opUSDT.

El flujo de trabajo para el puente de liquidez se verá así:

• Bloquear tokens nativos en la cadena de origen
• Representación del puente de acuñación del token nativo en la cadena de destino
• Intercambia la representación vinculada con la representación canónica en la cadena objetivo a través de la piscina AMM
• Enviar tokens canónicos al usuario

Este proceso es similar para todos los puentes de liquidez (Across, Celer, Hop, Stargate, etc.). Sin embargo, por lo general se abstrae del usuario final, especialmente por solucionadores/rellenadores, y parecerá como una sola transacción a pesar de involucrar muchas partes móviles.

Cuando se vuelve a conectar a la cadena de origen, el usuario quema la representación canónica o intercambia el token canónico por la representación del puente a través de la AMM antes de quemar esa representación y proporcionar el recibo de prueba de quema. Una vez confirmado, el usuario puede retirar los tokens nativos bloqueados al principio. (Al igual que en la operación anterior, los detalles de mover los tokens de vuelta a la cadena original están ocultos para el usuario y son gestionados por los solvers).

La interconexión de liquidez es excelente, principalmente porque soluciona el problema de latencia en la interconexión de rollup; por ejemplo, Hop permite a las partes especializadas conocidas como 'Bonders' dar fe de la validez de una transacción de retiro de un usuario en L2 y adelantar el costo del retiro del puente L1 del rollup. Cada Bonder ejecuta un nodo completo para la cadena L2 y puede determinar si la transacción de salida de un usuario será confirmada eventualmente en L1, reduciendo el riesgo de que un usuario inicie un retiro fraudulento y cause pérdidas al Bonder.

Los puentes de liquidez también permiten a los usuarios moverse entre más cadenas, a diferencia de los puentes canónicos; por ejemplo, Hop permite a los usuarios conectar entre Arbitrum y Optimism sin tener que retirarse a Ethereum primero. Al igual que el puente rápido de L2→L1, el puente rápido de L2→L2 requiere que los Bonderos ejecuten un nodo completo para la cadena L2 de origen para confirmar las retiradas antes de adelantar el costo de acuñar tokens para un usuario en la cadena L2 de destino. Esto permite una mayor composabilidad entre rollups y mejora drásticamente la experiencia del usuario, ya que los usuarios pueden mover tokens entre rollups sin problemas.

Pero la conexión de liquidez también tiene desventajas que afectan la utilidad de usar el puente consagrado de una cadena para acuñar la representación canónica de un token en una cadena L2/L1.

Desventajas de los puentes de liquidez

1. Deslizamiento

El deslizamiento es la diferencia entre la cantidad de tokens esperados y recibidos al interactuar con un AMM. El deslizamiento ocurre debido a que los AMM cotizan los intercambios según la liquidez actual en un grupo: la cotización es tal que se mantiene el equilibrio entre el saldo de cada activo en un par después de que se complete un intercambio, lo cual puede cambiar entre el momento en que un usuario inicia un intercambio y se ejecuta el intercambio.

La baja liquidez de los activos puente también puede aumentar el deslizamiento; si la piscina no tiene suficiente liquidez para reequilibrar un lado de la piscina, una gran operación puede cambiar el precio en gran medida y resultar en que los usuarios realicen intercambios a precios más altos. Se espera que los arbitrajistas ayuden a corregir las disparidades entre las piscinas que negocian el mismo activo, pero pueden desanimarse de las operaciones de arbitraje que involucren tokens con baja actividad / valor comercial.

Esto también afecta a los desarrolladores que construyen aplicaciones cross-chain, ya que deben tener en cuenta los casos extremos en los que ocurre un deslizamiento; el usuario no puede completar una operación cross-chain debido a recibir cantidades inferiores de un token en una o más cadenas de destino.

Aplicaciones como los agregadores de puentes (que no pueden saber si un puente de liquidez tendrá suficiente liquidez para cubrir un intercambio en la cadena de destino sin deslizamiento) solucionan el problema especificando una tolerancia máxima al deslizamiento y utilizando esa información para proporcionar cotizaciones a los usuarios. Si bien esto evita reversiones de transacciones, los usuarios siempre pierden un cierto porcentaje del token puente, independientemente de la liquidez en las pools de AMM de un puente.

2. Restricciones de liquidez

Un desafío fundamental con los puentes de liquidez es el requisito absoluto de suficiente liquidez en la cadena de destino. A diferencia de los puentes tradicionales de bloqueo y acuñación donde la acuñación de tokens está respaldada directamente por activos bloqueados, los puentes de liquidez dependen de los tokens disponibles en las piscinas de AMM para completar las transferencias entre cadenas. Cuando la liquidez cae por debajo de los umbrales críticos, el mecanismo de puente completo puede dejar de funcionar efectivamente.

• Las operaciones de puente pueden detenerse por completo si la liquidez cae demasiado, lo que impide que los usuarios completen sus transferencias previstas;
• Los usuarios pueden verse obligados a dividir transferencias grandes en transacciones más pequeñas para evitar agotar la liquidez de la pool;
• Durante períodos de alta volatilidad o estrés en el mercado, los proveedores de liquidez pueden retirarse de las pools, justo cuando se necesita más la funcionalidad de puente;
• El arranque de nuevos pares de tokens se vuelve particularmente desafiante, ya que se requiere una liquidez inicial significativa para hacer que el puente sea operativo.

El requisito de liquidez crea una dependencia circular: los puentes necesitan una liquidez sustancial para funcionar de manera confiable, pero atraer a proveedores de liquidez requiere demostrar un uso constante del puente y generación de comisiones. Este problema de huevo o gallina es particularmente grave para tokens nuevos o menos frecuentemente negociados, que pueden tener dificultades para mantener suficiente liquidez en múltiples cadenas.

3. Incentivos desalineados

Un puente de liquidez es útil en la medida en que pueda cubrir los intercambios desde la representación puenteada hasta el token canónico en la cadena de destino sin que los usuarios incurran en un deslizamiento excesivo; los costos de gas de interactuar con el puente también determinan el valor de un puente de liquidez desde la perspectiva del usuario. Por lo tanto, los agregadores de puentes y los equipos de proyectos que emiten un token priorizan los puentes en función de la cantidad de liquidez y los costos de transacción.

Si bien esto asegura que los usuarios que conectan tokens de un proyecto o utilizan un agregador de puentes para enviar tokens cross-chain tengan una mejor experiencia de usuario, seleccionar puentes basados en la liquidez coloca a los puentes que no pueden gastar en incentivos para proveedores de liquidez (LP) en desventaja. Además, seleccionar puentes basados en tarifas de transacción puras sesga la competencia a favor de puentes que adoptan un enfoque centralizado para reducir costos operativos y pueden cobrar tarifas más bajas en transacciones de puentes. En ambos casos, los puentes no compiten en lo que podría considerarse la métrica más importante: la seguridad.

Los puentes basados en liquidez también desfavorecen los activos de cola larga con menor actividad comercial (lo que los hace menos propensos a atraer LPs). Los emisores de tokens de cola larga (o nuevos tokens con bajos volúmenes de puente) tendrán que establecer piscinas AMM y arrancar liquidez para cubrir intercambios de tokens nativos (puenteados a través de un puente de liquidez) contra la representación canónica del token del emisor o trabajar con los operadores del puente para aumentar los incentivos financieros para que los LPs suministren liquidez para ese activo.

4. Mala experiencia de interconexión

Los puentes de liquidez son una mejora en los puentes canónicos, pero también tienen problemas de UX. Además de sufrir deslizamiento en intercambios cruzados entre cadenas, los usuarios pueden ser incapaces de completar una transacción de puente de inmediato en la cadena de destino porque el puente no tiene suficiente liquidez en el pool para cubrir el intercambio con el token canónico en la cadena de destino. Los puentes no pueden saber cuánta liquidez existirá para un par de activos cuando el mensaje del usuario para intercambiar tokens llegue a la cadena de destino, por lo que este caso extremo es en su mayoría inevitable.

Los usuarios tienen dos opciones en esta situación (ambas subóptimas):

• Espere hasta que el puente tenga suficiente liquidez para completar el intercambio y retirar los tokens canónicos. Esto no es óptimo debido al retraso sufrido en las transacciones de puente y porque el usuario no puede saber si recibirá la misma cantidad de tokens citados inicialmente, ya que la liquidez del pool puede cambiar arbitrariamente en períodos muy cortos.
• Reciba la representación del token propietario del puente (por ejemplo, hUSDT para Hop Bridge). Esto es subóptimo ya que la mayoría de las aplicaciones preferirán integrarse con la representación canónica de un token nativo (por ejemplo, opUSDT emitido por Optimism Bridge) y es posible que no acepten el activo envuelto del usuario.

2. Emitir tokens canónicos a través de un puente canónico de terceros.

Una dapp multi-cadena puede solucionar el problema de los tokens puente no fungibles seleccionando un único puente para crear representaciones canónicas del token de la dapp en cada cadena en la que se implementa la dapp. Al igual que con los puentes canónicos que crean representaciones aprobadas del token de un proyecto, este enfoque requiere mapear los tokens creados en cadenas remotas con el contrato de token implementado en la cadena de origen del proyecto, asegurando que el suministro de tokens se mantenga globalmente. El proveedor del puente debe seguir la creación y eliminación de un token y garantizar que las operaciones de creación y eliminación se mantengan sincronizadas con el suministro de tokens en la cadena de origen.

El uso de un único proveedor de puente ofrece más flexibilidad para los equipos de proyectos, especialmente porque se incentiva a los puentes de terceros a admitir el puenteado entre una gama más amplia de ecosistemas en comparación con los puentes canónicos que solo se conectan a lo sumo a una cadena. Si un puente existe en todas las cadenas donde se despliega una aplicación, los usuarios pueden moverse rápidamente entre cadenas sin necesidad de retirarse a la cadena original; el proveedor de puente solo tiene que asegurarse de que los tokens emitidos en la cadena de destino A se quemen antes de que un usuario emita tokens en la cadena de destino B y que los tokens canónicos en la cadena B se (re)mapeen al token en la cadena original.

También se elimina el problema de los tokens puente no fungibles; siempre y cuando los usuarios los conviertan a través del proveedor de puente aprobado, podrán intercambiarlos siempre en proporción de 1:1 con otros tokens puente. Este enfoque soluciona aún más los problemas de los puentes basados en liquidez en el modelo de puente canónico:

• Los usuarios no sufren deslizamiento en las transacciones de puente, ya que el proveedor de puente no tiene que convertir su representación contra una representación canónica a través de un AMM, el token del proveedor de puente es la representación canónica del token puente en cada dominio. El valor de estas representaciones está anclado al valor de los tokens bloqueados por el proveedor de puente en la cadena nativa del token.
• Los usuarios sufren poco o ningún retraso en el puente ya que el proveedor del puente puede crear representaciones envueltas en la cadena de destino inmediatamente después de que llegue el mensaje mint() al destino.
• Los desarrolladores pueden externalizar la gestión de despliegues de tokens multi-cadena a operadores de puente sin preocuparse por el inicio de la liquidez AMM o los programas de incentivos de provisión de liquidez.

Algunos ejemplos de tokens de proveedor de puente único en la naturaleza incluyen el Token Fungible Omnichain (OFT) de LayerZero, el Servicio de Token Interchain (ITS) de Axelar, el xAsset de Celer y cualquierToken de Multichain. Todos los ejemplos son tokens propietarios y no son compatibles con las representaciones del mismo token enviadas a través de un proveedor de puente diferente. Este detalle sutil destaca algunos problemas con este enfoque para manejar tokens de puente. A saber los siguientes:

• Vendor lock-in
• Pérdida de soberanía
• Alta exposición a fallos de puentes
• Pérdida de las características personalizadas del token en las cadenas de destino
• Estar limitado a las cadenas soportadas por el proveedor
• Incapacidad para mantener la misma dirección de token en todas las cadenas deseadas, lo que puede afectar la seguridad del usuario o dejarlo vulnerable a la pesca de datos

Desventajas de usar puentes de terceros canónicos

1. Vendor lock-in

Seleccionar un único proveedor de puente para acuñar representaciones canónicas en una o más cadenas expone a los desarrolladores al riesgo de quedar atrapados con un proveedor. Como cada proveedor de puente acuña una representación propietaria compatible solo con su infraestructura (y proyectos integrados en su ecosistema), el modelo de proveedor único de puente bloquea efectivamente a un emisor de tokens a un servicio de puente específico sin la opción de cambiar a otro puente en el futuro.

Es posible cambiar de proveedores de puente, pero los costos de cambio son lo suficientemente altos como para desalentar a la mayoría de los proyectos de seguir esta ruta. Para tener una idea aproximada, supongamos que un desarrollador (al que llamaremos Bob) ha emitido un token (BobToken) en Ethereum y elige LayerZero OFT para acuñar versiones canónicas de BobToken en Optimism, Arbitrum y Base. BobToken tiene un suministro fijo de 1.000.000 de tokens, y los tokens acuñados a través de LayerZero representan el 50% del suministro total de BobTokens en circulación.

El acuerdo comercial avanza sin problemas hasta que Bob decide que los usuarios están mejor conectando BobTokens a través de un servicio puente competidor (por ejemplo, Axelar). Sin embargo, Bob no puede simplemente decir: 'Estoy cambiando a Axelar ITS para generar representaciones canónicas de BobToken en Optimism, Base y Arbitrum'; dado que los tokens OFT y los tokens ITS son incompatibles, Bob corre el riesgo de crear problemas tanto para los antiguos usuarios como para los nuevos usuarios, ya que potencialmente hay dos BobTokens que no son fungibles (reintroduciendo el problema que describimos anteriormente). Además, las aplicaciones integradas con la versión de BobToken de LayerZero no pueden aceptar la versión de BobToken de Axelar como sustituto, lo que fragmenta la liquidez de BobToken en diversas cadenas donde coexisten representaciones competidoras de BobToken.

Para hacer posible la transición, Bob necesita convencer a los usuarios de desempaquetar las representaciones envueltas de BobToken acuñadas a través de LayerZero mediante el envío de una transacción que quema tokens OFT puenteados y desbloquea BobTokens en Ethereum. Los usuarios ahora pueden cambiar a la nueva representación canónica de BobToken bloqueando tokens con Axelar en Ethereum y recibiendo BobTokens canónicos (mapeados a la oferta del contrato de tokens en Ethereum) en la cadena de destino. Esto es tanto costoso como conlleva una coordinación masiva y una sobrecarga operativa para los equipos de gestión de proyectos de DAO, por lo que adherirse al proveedor elegido suele ser la opción más segura.

Sin embargo, esto deja a desarrolladores como Bob en una posición problemática, ya que el bloqueo del proveedor hace imposible cambiar si un proveedor de puente no cumple los términos del acuerdo, tiene un conjunto de funciones limitado, carece de integraciones en el ecosistema expansivo, ofrece una mala experiencia de usuario, etc. También proporciona a los puentes un apalancamiento casi infinito: el proveedor de puentes puede hacer cosas arbitrarias como limitar la velocidad de los usuarios que cruzan BobTokens sin razones claras, aumentar las tarifas de cruce, o incluso censurar operaciones de cruce. Las manos de Bob están atadas en este caso, ya que romper limpiamente con un puente de terceros canónico defectuoso es tan complejo como mantener la relación comercial.

2. Pérdida de soberanía para los protocolos

La parte final de la sección anterior sobre el bloqueo del proveedor resalta otro problema de usar un puente de terceros canónico: los emisores de tokens renuncian al control de los tokens canónicos de puente a cambio de una mayor comodidad y mejoras en la experiencia de usuario. Para usar el ejemplo anterior: BobToken en Ethereum está completamente bajo el control de Bob, ya que él controla el contrato de token ERC-20 subyacente, pero BobToken en Optimism, Arbitrum y Base están controlados por LayerZero, que es propietario del contrato OFT que emite representaciones canónicas de BobToken en esas blockchains.

Si bien Bob puede esperar que LayerZero alinee las representaciones canónicas con el diseño original del token nativo, esto puede no ser siempre el caso. En los peores escenarios, el comportamiento de BobToken en Ethereum puede divergir significativamente del de BobToken en Optimism debido a que el proveedor del puente implementa una versión radicalmente diferente del contrato del token, lo que crea problemas para los usuarios del protocolo. Este problema también puede ser exacerbado por dinámicas de agente principal donde los objetivos e intereses de un protocolo y el proveedor del puente divergen.

3. Alta exposición a fallas en puentes

En el primer enfoque, en el que los tokens se conectan entre cadenas a través del puente canónico de cada cadena, el riesgo para el emisor de tokens de un exploit que afecta a un puente se limita a ese puente. Por ejemplo, supongamos que un hacker logra comprometer un puente de liquidez y acuñar cantidades infinitas de un token envuelto sin depositar garantías. En ese caso, solo puede retirar hasta la liquidez máxima disponible para el activo envuelto en pools de liquidez (por ejemplo, acuñar cUSDT en Optimism → intercambiar cUSDT por opUSDT canónico → retirar opUSDT a Ethereum a través de un puente rápido → intercambio por USDT nativo en Ethereum).

En el modelo de puente canónico de terceros, el riesgo para un emisor de tokens de un exploit que afecta al puente socio es equivalente a la cantidad total de tokens que un atacante acuña en cadenas remotas donde el puente afectado tiene un despliegue. Esto es posible porque cada representación canónica en todas las cadenas puede intercambiarse 1:1 por tokens canónicos emitidos en otras cadenas:

Supongamos que un atacante compromete un puente de tercero en la cadena B y crea 1000 tokens (donde el token se emite inicialmente en la cadena A) sin depositar garantía. Los tokens del atacante en la cadena B no están mapeados al contrato de la cadena de origen, por lo que no puede retirarlos de la cadena A. Aun así, puede cruzar al la cadena C e intercambiar 1000 tokens de la cadena B por 1000 tokens de la cadena C—recuerda, cada token cruzado es compatible y fungible ya que provienen del mismo servicio de puente. Los tokens de la cadena C están mapeados al contrato de la cadena de origen ya que fueron legítimamente creados por usuarios que bloquearon tokens en la cadena A (la cadena de origen del token), permitiendo al atacante quemar tokens en la cadena C y retirar tokens nativos en la cadena A y potencialmente completar el itinerario intercambiando los tokens a través de un CEX o una salida a fiat.

(Fuente)

Pérdida de funciones de token personalizado

Cuando se utiliza un puente de terceros canónico, los emisores de tokens a menudo pierden la capacidad de implementar características personalizadas o comportamientos de tokens que existen en su implementación original. Esto sucede porque los proveedores de puentes tienden a utilizar contratos de implementación ERC-20 estandarizados que pueden no admitir funcionalidades especializadas presentes en la implementación original del token.

Características comunes de tokens como la delegación de votos (ZK), mecanismos de rebasing (stETH, USDM), capacidades de comisión por transferencia (memecoins), funciones de lista negra y lista blanca (USDT, USDC), transferencias pausables, y reglas o permisos especiales de acuñación a menudo se eliminan cuando los tokens se bridgan a través de un proveedor de terceros, ya que la versión bridgada generalmente utiliza una implementación básica ERC-20. Esta pérdida de funcionalidad crea inconsistencias en cómo opera el token en diferentes cadenas y potencialmente puede romper integraciones que dependen de estas características personalizadas.

La estandarización de tokens puentes, si bien es más sencilla desde la perspectiva del proveedor del puente, reduce efectivamente las capacidades del token y puede obstaculizar la capacidad del emisor para mantener un comportamiento de token consistente en todo el ecosistema multi-cadena de su aplicación. Estos problemas pueden convertir las expansiones entre cadenas en una pesadilla para los desarrolladores y representar un obstáculo para hacer realidad el sueño de las aplicaciones que viven en múltiples cadenas.

Cadenas admitidas limitadas

Los emisores de tokens se vuelven dependientes de la cobertura de red y los planes de expansión de su proveedor de puente elegido. Si el proveedor de puente no admite una red blockchain en particular a la que el emisor de tokens quiere expandirse, se enfrentan a dos opciones subóptimas:

• Espera a que el proveedor de puente agregue soporte para la cadena deseada, lo que puede llevar mucho tiempo o nunca suceder debido a los altos costos de integración (por ejemplo, la inequivalencia de EVM de la era ZKsync que ha llevado a muchos dapps a no desplegarse en ella)
• Utilice un proveedor de puente diferente para esa cadena específica, lo que reintroduce el problema de los tokens no fungibles y la fragmentación de la liquidez

Esta limitación puede afectar significativamente la estrategia de crecimiento de un protocolo y su capacidad para llegar a nuevos usuarios en cadenas emergentes. Los proveedores de puentes pueden priorizar el soporte a cadenas populares mientras descuidan redes más pequeñas o más nuevas que podrían ser estratégicamente importantes para el emisor del token.

Direcciones de token de cadena cruzada inconsistentes

Los proveedores de puentes de terceros pueden implementar tokens puente con direcciones diferentes en cada cadena debido a las peculiaridades de su pila tecnológica, por ejemplo, la falta de soporte para CREATE2. La falta de consistencia de direcciones, a su vez, crea muchos problemas de experiencia de usuario:

• Riesgos de seguridad: Los usuarios deben verificar las diferentes direcciones de los tokens en cada cadena, lo que aumenta el riesgo de interactuar con tokens fraudulentos;
• Complejidad de integración: Los desarrolladores deben mantener listas de direcciones de tokens válidas para cada red;
• Mayor riesgo de phishing: los actores malintencionados pueden engañar más fácilmente a los usuarios con tokens falsos ya que no hay una dirección consistente para verificar.

Estos inconvenientes, combinados con los problemas previamente discutidos de dependencia del proveedor, pérdida de soberanía y alta exposición a fallos del puente, destacan las limitaciones significativas de depender de puentes de terceros canónicos para despliegues de tokens entre cadenas. Esta comprensión ayuda a sentar las bases de por qué se necesitan soluciones alternativas como ERC-7281 para abordar estos desafíos de una manera más integral.

3. Emitir tokens canónicos a través del puente del emisor de tokens

Si un desarrollador desea mantener el control máximo de las implementaciones intercadenas de los tokens de un proyecto, puede administrar la emisión de representaciones canónicas del token en cadenas remotas. Esto se describe como 'confiar en el emisor del token', ya que el valor de cada representación interconectada del token está vinculado a los tokens bloqueados en la cadena de origen del token por el protocolo responsable de emitir la versión original del token en la cadena fuente.

Para que ese enfoque funcione, el emisor del token debe configurar la infraestructura para manejar la emisión y destrucción de tokens cruzados entre cadenas (mientras se asegura de que el suministro global permanezca sincronizado a través del mapeo canónico).

Ejemplos destacados de representaciones canónicas de un token emitido por el creador del token son Teleport de MakerDAO y de Circle's Protocolo de transferencia entre cadenas (CCTP). Teleport permite a los usuarios mover DAI canónico entre Ethereum y varios rollups de Ethereum a través de operaciones de ruta rápida y ruta lenta. DAI se quema en una cadena y se acuña en la cadena de destino. CCTP funciona de manera similar y permite transferencias cross-chain de USDC nativo (emitido por Circle) a través de un mecanismo de quemado y acuñado. En ambos casos, el emisor del token controla la acuñación y quema de representaciones canónicas de un token.

Este enfoque ofrece un control completo de los tokens puente para los protocolos. Y resuelve el problema de las representaciones no fungibles del mismo token de la manera más efectiva posible: solo existe una versión canónica del token (acuñada por el emisor en la cadena de destino), lo que garantiza que los usuarios tengan la misma experiencia al usar un token en cada ecosistema que el emisor del token admite.

Con este enfoque, las aplicaciones también se benefician de la eliminación de la fragmentación de liquidez causada por representaciones no oficiales, puentes de un protocolo de tokens flotantes en el mismo ecosistema. Los desarrolladores también pueden construir aplicaciones cross-chain más robustas (por ejemplo, intercambios cross-chain y préstamos cross-chain) ya que los puentes del emisor de tokens canónicos permiten un movimiento eficiente, fluido y seguro de tokens entre cadenas.

Sin embargo, el inconveniente de los puentes de emisores de tokens canónicos es que este modelo solo es factible para proyectos con suficiente capital para cubrir los gastos generales de implementar un token cross-chain y mantener la infraestructura (oráculos, guardianes, etc.) necesaria para realizar la creación y quema de tokens cross-chain. Esto también tiene el efecto algo indeseable de acoplar estrechamente la seguridad de los activos puenteados con el modelo de seguridad del protocolo.

Esta relación (entre las versiones puente de los tokens de un protocolo y la seguridad del protocolo) es amistosa, ya que la seguridad de los tokens nativos que respaldan las representaciones canónicas ya depende de la seguridad del protocolo, por lo que los usuarios y los desarrolladores externos no asumen nuevas suposiciones de confianza. Esto es especialmente cierto de puentes de stablecoinoperado por emisores como Circle y Maker (ahora Sky) - los usuarios ya confían en que los emisores de stablecoins tienen suficientes activos para cubrir el canje de stablecoins por monedas fiduciarias, por lo que confiar en la seguridad de un puente de stablecoins no es difícil.

Pero también representa un punto central de falla: si la infraestructura de puente del emisor del token se ve comprometida, el valor de todas las representaciones canónicas que circulan en el ecosistema multi-cadena está en peligro. Esto también implica que solo los custodios centralizados (por ejemplo, Circle en el caso de USDC) pueden implementar este modelo de emisión de tokens de puente canónicos.

Pensamientos finales

Como se muestra en este informe, la fungibilidad de los activos entre cadenas es una parte importante de la interoperabilidad de rollup con implicaciones para la experiencia de moverse entre diferentes cadenas. La capacidad de los tokens de mantenerse fungibles al ser puenteados a cadenas remotas también afecta la experiencia de los desarrolladores, ya que ciertos casos de uso dependen de esta característica.

Si bien estos enfoques resuelven problemas específicos, no logran abordar todas las cuestiones y utilizarlos para habilitar la fungibilidad de activos entre cadenas requiere algunos compromisos indeseables. ¿Podemos encontrar un mejor enfoque? La respuesta es sí.

ERC-7281 es un nuevo enfoque para la fungibilidad de activos entre cadenas que mitiga los compromisos asociados con los enfoques existentes. También conocido como xERC-20, ERC-7281 permite a los protocolos implementar tokens canónicos en varias cadenas de manera eficiente sin comprometer la seguridad, la soberanía o la experiencia del usuario.

El diseño único de ERC-7281 permite que varios puentes (en lista blanca) emitan versiones canónicas de los tokens de un protocolo en cada cadena admitida, al tiempo que permite a los desarrolladores del protocolo ajustar dinámicamente los límites de emisión en función de cada puente. Esta característica resuelve muchos de los problemas asociados con propuestas históricas para tokens canónicos de múltiples cadenas, incluida la fragmentación de liquidez, la alineación de incentivos, las preocupaciones de UX, los riesgos de seguridad del puente, la personalización (de tokens entre cadenas) y más.

La siguiente y última parte de nuestro informe en dos partes sobre la fungibilidad de activos entre cadenas cubrirá en detalle ERC-7281 y explorará cómo el estándar de token xERC-20 puede beneficiar a los desarrolladores y usuarios. Compararemos ERC-7281 con otros diseños de tokens canónicos multichain, exploraremos el enfoque de xERC-20 para los tokens canónicos multichain y destacaremos consideraciones para los protocolos y desarrolladores que deseen construir sobre el estándar.

¡Manténgase atento!

Descargo de responsabilidad:

1. Este artículo es una reimpresión de [Investigación 2077]. Todos los derechos de autor pertenecen al autor original [Alex HookyEmmanuel Awosika]. Si hay objeciones a esta reimpresión, por favor contacta al Gate Learnel equipo lo manejará rápidamente.
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. Las traducciones del artículo a otros idiomas son realizadas por el equipo de aprendizaje de gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.