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 cadenas de bloques como Alicia en el País de las Maravillas. ¿Por qué quedarse con una cadena si puede acceder a tecnología de vanguardia, aplicaciones novedosas, retornos descomunales en staking/provisión de liquidez, alto rendimiento y tarifas de transacción ultrabajas en otras cadenas de bloques?

Pero moverse entre cadenas de bloques es mucho más complicado que el viaje de Alicia por el País de las Maravillas, principalmente debido a las limitaciones inherentes a los enfoques actuales de interoperabilidad de cadenas de bloques (por ejemplo, los puentes entre cadenas). En particular, los puentes entre cadenas actuales son inseguros (se han perdido más de 2500 millones de dólares en ataques a puentes), lentos, caros o tienen una funcionalidad limitada, o presentan una combinación de las propiedades de la lista.

Otros problemas que afectan a la industria de los puentes son más sutiles, pero aún así son suficientes para convertir el sueño de los maxi modulares de un ecosistema multicadena en una pesadilla para los usuarios y desarrolladores. Un ejemplo de esto es cómo los tokens fungibles (como los ERC-20) se vuelven no fungibles cuando se conectan a diferentes cadenas a través de varios protocolos entre cadenas, lo que perjudica sus características como activo transferible. En este artículo, exploraremos una solución que busca preservar la fungibilidad de los tokens entre cadenas independientemente de dónde exista el contrato de origen de un token: ERC-7281: tokens con puentes soberanos.

ERC-7281 extiende ERC-20 (el estándar de facto para crear tokens fungibles en Ethereum) para permitir la acuñación y quema de representaciones canónicas de tokens ERC-20 en dominios remotos por múltiples puentes aprobados por los emisores de tokens. Esto garantiza que los usuarios que puentean un token ERC-20 reciban versiones fungibles del token en el destino (es decir, se pueden intercambiar dos tokens 1:1), incluso cuando los tokens se envían entre cadenas a través de diferentes rutas/puentes. Es importante destacar que los protocolos que adoptan ERC-7281 mantienen el control de los tokens puenteados (a diferencia del status quo donde el puente controla un token puenteado) y pueden limitar la velocidad de las operaciones de acuñación para reducir la exposición en caso de una falla del puente.

Utilicemos USDC como ejemplo de infungibilidad entre tokens ERC-20 teóricamente idénticos en diferentes cadenas. En las redes de capa 2 (L2) de Ethereum , como Arbitrum, Base y Optimism, es común usar el puente canónico para mover tokens ERC-20 populares desde la capa 1 de Ethereum a estas cadenas. Estas versiones de tokens L2 originados en la capa 1 se denominan comúnmente simplemente "[insertar nombre del token] con puente".

En el caso de USDC, los símbolos comunes son USDC.e, USDC.b, etc. Con el tiempo, Circle expande sus implementaciones de USDC a otras cadenas, incluidas las L2, donde USDC ya está activo a través del puente canónico. Aunque estos dos tokens son acuñados por la misma entidad y tienen el mismo precio, técnicamente son tokens diferentes e infungibles, por lo tanto, no son "interoperables": mientras que el USDC nativo se puede conectar a través del puente CCTP de Circle, el USDC conectado solo se puede conectar de nuevo a la L1 a través del puente canónico.

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

Si bien ERC-7281 no es el primer intento de crear tokens fungibles entre cadenas, corrige 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 generar liquidez para los tokens puenteados, la sobrecarga de infraestructura y una mayor exposición a fallas de los puentes.

Este informe de dos partes examinará la justificación para introducir un estándar de tokens con puente soberano y proporcionará una descripción general completa de la especificación ERC-7281 (también conocida como xERC-20). También analizaremos los beneficios positivos y los posibles inconvenientes de la implementación de ERC-7281 para los usuarios, desarrolladores, proveedores de infraestructura y otros actores del ecosistema Ethereum.

Un repaso de los puentes blockchain

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

Un puente es un mecanismo para transferir información entre cadenas de bloques . Además de información puramente monetaria, los puentes pueden pasar cualquier información útil, como tasas de tokens y estados de contratos inteligentes en otras cadenas. Sin embargo, la transferencia de 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 puenteo de tokens generalmente siguen uno de tres patrones de alto nivel:

Puentes de cerradura y de ceca

• Un usuario desea transferir un token desde su cadena nativa o "local" (donde se emitió inicialmente) a otra cadena. Las dos cadenas de bloques no son interoperables, ya que cada cadena implementa diferentes arquitecturas y diseños de protocolo, lo que impide que el usuario transfiera 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 implementado en la cadena de destino.

• Cuando el usuario desea hacer un puente en la dirección inversa (cadena de destino → cadena de origen), devuelve los tokens envueltos al puente en la cadena de destino, que lo verifica de acuerdo con la lógica del puente (por ejemplo, pruebas ZK o un quórum externo) y libera los tokens originales del depósito en garantía en la cadena de origen.

  
  

Quemar y acuñar puentes

• En lugar de bloquear los tokens en depósito, este enfoque quema (destruye) los tokens en la cadena de origen;

• El puente luego acuña una cantidad equivalente en la cadena de destino;

• Para el viaje inverso, los tokens puenteados se queman en la cadena de destino antes de que se acuñen nuevos tokens en la cadena de origen;

• Esto mantiene el suministro total de tokens al tiempo que permite 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 swaps atómicos funcionan mediante el bloqueo mutuo de fondos con el mismo valor secreto para desbloquearlos, lo que significa que si el secreto fue revelado por cualquiera de las partes, también puede revelarse por la otra. Esto le otorga a los swaps la propiedad de atomicidad.
• La atomicidad significa que el intercambio se completa totalmente (en ambos lados) o no se completa en absoluto, lo que evita fraudes o transferencias parciales o fallidas.

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

Sin embargo, los 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 delinear pasos específicos para lograr los resultados. Las intenciones han surgido como un poderoso elemento de desbloqueo de la experiencia de usuario, ya que simplifican enormemente la experiencia en cadena para las personas y hacen que las criptomonedas sean más fáciles de usar, particularmente cuando se combinan con soluciones de abstracción de cadena .

Las intenciones entre cadenas permiten 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 el resultado deseado en la cadena de destino (su "intención"). Los operadores especializados llamados "rellenadores" o "solucionadores" pueden cumplir esta intención enviando los tokens solicitados al usuario en la cadena de destino por adelantado. Luego, los operadores prueban que se produjo la transferencia para reclamar los fondos bloqueados en la cadena de origen como reembolso.

Algunos puentes basados en intenciones aprovechan mecanismos de bloqueo y acuñación en segundo plano. En este caso, el puente acuña tokens envueltos que se envían al rellenador que cumplió con la intención del usuario, o directamente al usuario si no intervino ningún rellenador. Si bien los puentes basados en intenciones agregan una capa adicional de eficiencia a través de su red de solucionadores, aún 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 pagaré 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 garantía en la cadena de origen del token.

El puente autorizado para bloquear los tokens subyacentes en la cadena de origen y acuñar sus representaciones envueltas en la cadena de destino garantiza que el suministro total de tokens se mantenga constante. Por cada unidad del token subyacente, se acuña 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 que el proveedor del puente asegure 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 (posibilitada por puentes que crean representaciones del activo) es una característica poderosa que permite a los desarrolladores y usuarios aprovechar los beneficios de la interoperabilidad entre cadenas. Algunos de estos beneficios incluyen acceso a mayor liquidez, exposición a nuevos usuarios y flexibilidad para los usuarios (que pueden interactuar con sus aplicaciones favoritas de diferentes cadenas sin fricción).

Para entender 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 exchange descentralizado ficticio llamado BobDEX. Este ejemplo demostrará cómo los tokens envueltos permiten la expansión entre cadenas y, al mismo tiempo, destacará los beneficios y las posibles complicaciones que pueden surgir:

BobDEX es un exchange de creadores de mercado automatizados (AMM) que Bob creó en Ethereum para permitir intercambios sin confianza entre diferentes activos. BobDEX tiene un token nativo, $BOB, que funciona como token de gobernanza y token de recompensa de LP. En este último caso, BobDEX emite tokens BOB a los proveedores de liquidez (LP), lo que da derecho a los usuarios que suministran liquidez a un fondo a un porcentaje de las tarifas pagadas por los usuarios de DEX que intercambian activos depositados en el fondo.

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

Para resolver el problema, Bob implementa una versión de BobDEX en Arbitrum (un paquete de implementación de capa 2 (L2) de bajo costo y alto rendimiento) e implementa una versión encapsulada 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 usa wBOB (no tokens BOB nativos) para las recompensas y la gobernanza de LP.

La diferencia entre los tokens de aplicación (BOB envuelto y BOB nativo) no supone ninguna diferencia desde la perspectiva de los usuarios (por ejemplo, los proveedores de liquidez) que interactúan con BobDEX en Arbitrum. Dado que los tokens wBOB están respaldados por tokens BOB reales almacenados en el puente Arbitrum-Ethereum, los poseedores de tokens wBOB pueden intercambiarlos fácilmente por tokens BOB ERC-20 nativos en Ethereum interactuando con el contrato del puente.

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

1. Bob puede atraer a más usuarios, especialmente a aquellos que desean tarifas de gas bajas y confirmaciones de transacciones rápidas al operar en BobDEX.

2. Los LP pueden ganar recompensas al suministrar liquidez a BobDEX sin tener que lidiar con los altos costos de gas de Ethereum y los largos tiempos de confirmación.

3. Los hodlers pueden comprar tokens wBOB en el mercado para beneficiarse de los cambios en el precio de los tokens BOB sin interactuar con el contrato BOB ERC-20 en Ethereum

   
   

Los beneficios de la creación de puentes también se extienden a la mejora de la innovación componible y al desbloqueo de nuevos casos de uso que aprovechan la liquidez de un token puenteado. Por ejemplo, Alice puede crear un protocolo de préstamos llamado AliceLend en Arbitrum que acepta wBOB como garantía de los prestatarios para ampliar la utilidad de wBOB y crear un nuevo mercado para préstamos y empréstitos .

Los prestamistas que proporcionan liquidez a AliceLend tienen la certeza de recibir los 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 tokens BOB originales.

El puente entre cadenas en su forma actual ha proporcionado una solución viable para garantizar la interoperabilidad entre las capas 2 de Ethereum (anteriormente aisladas) y facilitar aplicaciones novedosas (por ejemplo, préstamos entre cadenas y DEX entre cadenas). Pero el ecosistema de puentes actualmente se enfrenta a limitaciones que impiden un mayor crecimiento, como la no fungibilidad de los tokens entre cadenas; exploraremos este problema en detalle más adelante.

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

El flujo de trabajo de conexión de cerradura y acuñación descrito anteriormente parece simple en el papel, pero, en realidad, requiere mucho esfuerzo de ingeniería y diseño de mecanismos para funcionar correctamente:

El primer desafío es garantizar que las versiones envueltas de un token puente estén siempre 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 (acuñados fraudulentamente) con tokens nativos en la cadena de origen e impedir que los usuarios legítimos (que depositaron en el contrato puente antes de crear tokens envueltos) retiren los depósitos.

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

• Alice conecta USDC de 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 que puede entregarle a Bob. Bob está confundido, ya que se supone que los tokens ERC-20 envueltos son "fungibles" y no deberían presentar disparidades que impidan que alguien intercambie tokens ERC-20 1:1 en cualquier aplicación.
• Bob aprende una dura lección sobre los puentes entre cadenas: un “token ERC-20 fungible” no siempre significa que “puedes intercambiar este token 1:1 con otros tokens ERC-20 en distintas aplicaciones”. El intento de Bob de hacer negocios riesgosos con Alice (riesgosos porque Alice podría no devolver los tokens) sale estrepitosamente mal.

¿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 pagaré del puente que promete devolver una cantidad de los tokens nativos (dependiendo de cuánto quede) cuando el usuario desee volver a la cadena nativa del token.

El valor de cada token puenteado está entonces ligado al proveedor puente responsable de mantener los depósitos en la cadena de origen y acuñar representaciones en la cadena de destino; el proveedor puente de Bob solo puede pagarle a Bob 200 USDC ya que esa es la cantidad que tiene fondos para cubrir de su depósito; los 200 USDC de Alice no se pueden retirar a través del proveedor puente de Bob ya que nunca recibió el depósito ni emitió un pagaré a Alice. Alice debe retirar sus USDC bloqueados del Arbitrum en Ethereum y hacer el puente a través del proveedor 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 creación de puentes entre dominios en los que proveedores de puentes que compiten entre sí crean múltiples representaciones no fungibles de un activo subyacente. El otro problema con las diferentes representaciones ERC-20 del mismo activo es que no se pueden comercializar en un único fondo de liquidez.

Usando el ejemplo anterior, si tenemos axlUSDC y USDC.e en la cadena y queremos intercambiarlos por ETH y viceversa, debemos implementar dos fondos de liquidez: ETH/axlUSDC y ETH/USDC.e. Esto conduce a un problema llamado “fragmentación de liquidez”, una situación en la que los fondos de negociación tienen una liquidez menor de la que podrían tener de otra manera porque hay múltiples fondos que se adaptan esencialmente al mismo par de negociación.

La solución es tener una única versión “canónica” de un token que circule en la cadena de destino, de modo que Bob y Alice puedan intercambiar tokens sin que cada persona se retire 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 tener que lidiar con problemas relacionados con la liquidez de los tokens.

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

Implementación de tokens canónicos en diferentes cadenas

Crear un token canónico por cadena no es sencillo y existen múltiples opciones con diferentes ventajas y desventajas. Al crear un token canónico por cadena, generalmente debemos pensar en quién confiar en cuanto a la existencia de pagarés que respalden el valor de un token en particular.

Supongamos que usted es el creador de un token y desea que sea utilizable y transferible entre diferentes cadenas sin encontrarse con problemas de fungibilidad; tiene cuatro opciones:

1. Acuñar tokens canónicos a través de puentes de cadenas laterales/rollup canónicos
2. Acuñar tokens canónicos a través de un proveedor puente externo
3. Acuñar tokens canónicos a través de un puente entre tokens y emisores
4. Emisión directa de múltiples cadenas con swaps atómicos

Las primeras tres opciones se basan en varios mecanismos de puenteo para facilitar el movimiento de tokens entre cadenas. Sin embargo, como creador de tokens, también puede optar por omitir el puenteo por completo emitiendo el token de forma nativa en cada cadena compatible. Con este enfoque, en lugar de depender de tokens envueltos o infraestructura de puenteo, mantiene 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 las 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 de cadenas laterales/rollup canónicos

Si una cadena tiene un puente canónico (consagrado), puedes asignar el derecho a acuñar representaciones del token de tu protocolo para los usuarios que quieran crear un puente desde la cadena nativa. Las transacciones enrutadas 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, 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 creadas.

Aunque el puente canónico está acuñando 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, la conexión desde Arbitrum/Optimism a Ethereum a través del puente canónico del rollup incurre en una demora de siete días ya que las transacciones deben ser validadas por verificadores (y posiblemente disputadas por una prueba de fraude , si no son válidas) antes de que la capa de liquidación del rollup (Ethereum) liquide un lote de transacciones.

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

Las cadenas laterales con conjuntos de validadores independientes tienen una latencia menor, ya que los retiros se ejecutan una vez que el protocolo de consenso de la cadena lateral confirma un bloque que contiene una transacción de retiro. El puente PoS de Polygon es un ejemplo de un puente canónico que conecta una cadena lateral con diferentes dominios (incluidos los rollups de Ethereum y la red principal de Ethereum).

Nota: Nos referimos a la cadena PoS original de Polygon, no a la cadena Validium planificada que utilizará Ethereum para la liquidación. Polygon se convertirá en una cadena L2 una vez que se complete el cambio de una cadena lateral protegida por validadores externos a un Validium protegido por el consenso de Ethereum.

Sin embargo, los puentes de cadenas laterales también comparten una debilidad con los puentes canónicos de acumulación: los usuarios solo pueden hacer puentes entre un par de cadenas conectadas. No pueden hacer puentes con otras cadenas de bloques utilizando el puente canónico. Por ejemplo, hoy en día no se puede hacer un puente de Arbitrum a Optimism utilizando el puente de Arbitrum ni un puente de Polygon a Avalanche a través del puente PoS de Polygon.

1.1. Acuñar tokens canónicos mediante puentes de liquidez

Depender del puente nativo de un rollup para mover tokens canónicos conlleva varios problemas, como poca liquidez y demoras en el movimiento de activos. Los protocolos solucionan este problema trabajando con puentes de liquidez para facilitar retiros rápidos y puentes de baja latencia*.

En virtud de este acuerdo, los puentes de liquidez aprobados (a) acuñan representaciones envueltas del token de un protocolo en la cadena de origen (b) intercambian tokens envueltos por la representación canónica en el destino a través de un fondo 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 cadena lateral/rollup canónico, 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 swaps entre pares de activos depositados en diferentes pools de liquidez. Para incentivar la provisión de liquidez, los pools AMM comparten una parte de las tarifas de swap 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 del puente de liquidez de un token contra la representación canónica. Por ejemplo, un usuario que hace un puente entre USDT y Optimism a través de Hop tendrá que intercambiar hUSDT en Optimism a través del pool huSDT:opUSDT.

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

• Bloquear tokens nativos en la cadena de origen
• Representación del token nativo en el puente Mint en la cadena de destino
• Intercambio de representación en puente con representación canónica en la cadena de destino a través del grupo AMM
• Enviar tokens canónicos al usuario

Este proceso es similar para todos los puentes de liquidez (Across, Celer, Hop, Stargate, etc.). Sin embargo, generalmente no se realiza en el usuario final (en particular, por parte de los solucionadores y los encargados de rellenar) y parece una única transacción a pesar de que implica muchas partes en movimiento.

Al volver a la cadena de origen, el usuario quema la representación canónica o intercambia el token canónico con la representación del puente a través del 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 sucios de mover los tokens de vuelta a la cadena original se ocultan al usuario y los gestionan los solucionadores).

El puente de liquidez es excelente, principalmente porque soluciona el problema de latencia en el puente de acumulación; por ejemplo, Hop permite que partes especializadas conocidas como "Bonders" den fe de la validez de la transacción de retiro de un usuario en L2 y asuman el costo de retiro del puente L1 de la acumulación. Cada Bonder ejecuta un nodo completo para la cadena L2 y puede determinar si la transacción de salida de un usuario finalmente se confirmará en L1, lo que reduce el riesgo de que un usuario inicie un retiro fraudulento y cause pérdidas para el 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 hacer un puente entre Arbitrum y Optimism sin tener que retirar primero a Ethereum. Al igual que el puente rápido L2→L1, el puente rápido L2→L2 requiere que los Bonders ejecuten un nodo completo para la cadena L2 de origen para confirmar los retiros antes de afrontar el costo de acuñar tokens para un usuario en la cadena L2 de destino. Esto permite una mayor componibilidad entre los rollups y mejora drásticamente la experiencia del usuario, ya que los usuarios pueden mover tokens entre los rollups sin problemas.

Pero el puente 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. Analizamos las desventajas del puente basado en liquidez en la siguiente sección:

Desventajas de los puentes de liquidez

1. Deslizamiento

El deslizamiento es una diferencia en la cantidad de tokens esperados y recibidos al interactuar con un AMM. El deslizamiento ocurre debido a que los AMM fijan el precio de los swaps de acuerdo con la liquidez actual en un pool: el precio es tal que se mantiene el equilibrio entre el saldo del pool de cada activo en un par después de que se completa un swap, lo que puede cambiar entre el momento en que un usuario inicia una operación y el momento en que se ejecuta el intercambio.

La baja liquidez de los activos puenteados también puede aumentar el deslizamiento; si el pool no tiene suficiente liquidez para reequilibrar un lado del pool, una operación grande puede cambiar el precio por un amplio margen y hacer que los usuarios ejecuten swaps a precios más altos. Se espera que los arbitrajistas ayuden a corregir las disparidades entre los pools que comercian el mismo activo, pero se les puede disuadir de realizar operaciones de arbitraje que involucren tokens con baja actividad comercial o valor.

Esto también afecta a los desarrolladores que crean aplicaciones entre cadenas, ya que deben tener en cuenta casos extremos en los que se produce un deslizamiento. El usuario no puede completar una operación entre cadenas debido a que recibe cantidades inferiores de un token en una o más cadenas de destino.

Las aplicaciones como los agregadores de puentes (que no pueden saber si un puente de liquidez tendrá suficiente liquidez para cubrir un swap en la cadena de destino sin deslizamiento) resuelven el problema especificando una tolerancia máxima de deslizamiento y utilizándola para informar las cotizaciones proporcionadas a los usuarios. Si bien esto evita las reversiones de transacciones, los usuarios siempre pierden un porcentaje del token puenteado, independientemente de la liquidez en los pools AMM de un puente.

2. Restricciones de liquidez

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

• Las operaciones del puente pueden detenerse por completo si la liquidez cae demasiado, impidiendo a los usuarios completar sus transferencias previstas;
• Los usuarios pueden verse obligados a dividir transferencias grandes en transacciones más pequeñas para evitar agotar la liquidez del fondo;
• Durante períodos de alta volatilidad o estrés en el mercado, los proveedores de liquidez pueden retirarse de los fondos, precisamente cuando la funcionalidad del puente es más necesaria;
• La creación de nuevos pares de tokens se vuelve particularmente desafiante, ya que se requiere una liquidez inicial significativa para que el puente esté operativo.

El requisito de liquidez crea una dependencia circular: los puentes necesitan una liquidez sustancial para funcionar de manera confiable, pero para atraer proveedores de liquidez es necesario demostrar un uso constante de los puentes y la generación de tarifas. Este problema del huevo y la gallina es particularmente agudo para los tokens nuevos o que se comercializan con menos frecuencia, que pueden tener dificultades para mantener una liquidez suficiente en múltiples cadenas.

3. Incentivos desalineados

Un puente de liquidez es útil en la medida en que puede 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 la interacción 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 garantiza que los usuarios que conectan los tokens de un proyecto o usan un agregador de puentes para enviar tokens entre cadenas tengan una mejor experiencia de usuario, la selección de puentes en función de la liquidez coloca a los puentes que no pueden gastar en incentivos de proveedores de liquidez (LP) en desventaja. Además, la selección de puentes en función de tarifas de transacción puras sesga la competencia a favor de los puentes que adoptan un enfoque centralizado para reducir los costos operativos y pueden cobrar tarifas más bajas en las transacciones de conexión. En ambos casos, los puentes no compiten en lo que podría decirse que es la métrica más importante: la seguridad.

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

4. Mala experiencia de conexión

Los puentes de liquidez son una mejora con respecto a los puentes canónicos, pero también presentan problemas de experiencia de usuario. Además de soportar el deslizamiento en los intercambios entre cadenas, es posible que los usuarios no puedan completar una transacción de puente de inmediato en la cadena de destino porque el puente no tiene suficiente liquidez en el fondo para cubrir el comercio con el token canónico en la cadena de destino. Los puentes no pueden saber cuánta liquidez para un par de activos existirá en el momento en que el mensaje de un usuario para intercambiar tokens llegue a la cadena de destino, por lo que este caso extremo es casi 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 a la demora que se sufre en las transacciones de puente y porque un usuario no puede saber si recibirá la misma cantidad de tokens cotizados inicialmente, ya que la liquidez del pool puede cambiar arbitrariamente en períodos muy cortos.
• Recibir la representación del token propietario del puente (por ejemplo, hUSDT para Hop Bridge) . Esto no es ó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 acuñado por Optimism Bridge) y es posible que no acepten el activo encapsulado del usuario.

2. Acuñar tokens canónicos a través de un puente canónico de terceros

Una aplicación descentralizada multicadena puede solucionar el problema de los tokens puente no fungibles seleccionando un único puente para acuñar representaciones canónicas del token de la aplicación en cada cadena en la que se implementa la aplicación. Al igual que con los puentes canónicos que acuñan representaciones aprobadas del token de un proyecto, este enfoque requiere mapear los tokens acuñados en cadenas remotas al contrato de token implementado en la cadena de origen del proyecto, lo que garantiza que el suministro de tokens siga siendo el mismo a nivel global. El proveedor del puente debe realizar un seguimiento de la acuñación y la quema de un token y garantizar que las operaciones de acuñación y quema se mantengan sincronizadas con el suministro de tokens en la cadena de origen.

El uso de un único proveedor de puentes ofrece más flexibilidad a los equipos de proyectos, especialmente porque los puentes de terceros tienen incentivos para respaldar la creación de puentes entre una gama más amplia de ecosistemas en comparación con los puentes canónicos que solo se conectan a una sola cadena como máximo. Si existe un puente en todas las cadenas en las que se implementa una aplicación, los usuarios pueden moverse rápidamente entre cadenas sin necesidad de volver a la cadena de origen; un proveedor de puentes solo tiene que asegurarse de que los tokens acuñados en la cadena de destino A se quemen antes de que un usuario acuñe tokens en la cadena de destino B y los tokens canónicos en la cadena B se (re)asignen al token en la cadena de origen.

También se elimina el problema de los tokens puente no fungibles; siempre que los usuarios utilicen el puente a través del proveedor de puentes aprobado, siempre pueden intercambiarlos 1:1 con otros tokens puenteados. Este enfoque soluciona aún más los problemas del puenteo basado en la liquidez en el modelo de puente canónico:

• Los usuarios no sufren retrasos en las transacciones de puente, ya que el proveedor de puente no tiene que convertir su representación en 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 puenteado en cada dominio. El valor de estas representaciones está vinculado 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 puenteo ya que el proveedor del puente puede crear representaciones envueltas en la cadena de destino inmediatamente después de que el mensaje mint() llega al destino.

• Los desarrolladores pueden subcontratar la gestión de implementaciones de tokens multicadena a operadores puente sin preocuparse por impulsar la liquidez de AMM o los programas de incentivos de provisión de liquidez.

  
  

Algunos ejemplos de tokens de un único proveedor de puentes en la red incluyen Omnichain Fungible Token (OFT) de LayerZero, Interchain Token Service (ITS) de Axelar, xAsset de Celer y anyAsset de Multichain. Todos los ejemplos son esencialmente tokens propietarios y son incompatibles con las representaciones del mismo token enviadas a través de un proveedor de puentes diferente. Este sutil detalle resalta algunos problemas con este enfoque para manejar tokens puenteados. A saber, los siguientes:

• Bloqueo del proveedor
• Pérdida de soberanía
• Alta exposición a fallas en puentes
• Pérdida de las características personalizadas del token en las cadenas de destino
• Estar limitado a las cadenas admitidas por el proveedor
• Incapacidad de mantener la misma dirección de token en todas las cadenas deseadas, lo que puede dañar la seguridad del usuario o exponerlo a phishing

Desventajas de utilizar puentes canónicos de terceros

1. Bloqueo del proveedor

La selección de un único proveedor de puentes para generar representaciones canónicas en una o más cadenas expone a los desarrolladores al riesgo de quedar atrapados en un proveedor. Como cada proveedor de puentes genera una representación patentada compatible únicamente con su infraestructura (y proyectos de ecosistemas integrados), el modelo de un único proveedor de puentes 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 proveedor de puentes, pero los costos de cambio son lo suficientemente altos como para disuadir a la mayoría de los proyectos de seguir este camino. Para dar una idea aproximada, supongamos que un desarrollador (a quien 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 puente acuñados a través de LayerZero representan el 50% del suministro total de BobTokens en circulación.

El acuerdo comercial se desarrolla sin problemas hasta que Bob decide que es mejor para los usuarios hacer un puente entre los BobTokens a través de un servicio de puente competidor (por ejemplo, Axelar). Sin embargo, Bob no puede simplemente decir: "Me voy a cambiar a Axelar ITS para acuñar 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 dolores de cabeza tanto para los usuarios antiguos como para los nuevos, ya que dos BobTokens potencialmente no son fungibles (lo que reintroduce 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 varias cadenas donde coexisten representaciones competidoras de BobToken.

Para que la transición sea posible, Bob debe convencer a los usuarios de que desempaqueten las representaciones envueltas de BobToken acuñadas a través de LayerZero mediante el envío de una transacción que queme tokens OFT puenteados y desbloquee 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 (asignados al suministro del contrato de tokens en Ethereum) en la cadena de destino. Esto es costoso y genera una enorme sobrecarga operativa y de coordinación para los equipos de gestión de proyectos de DAO, por lo que quedarse con el proveedor elegido suele ser la opción más segura.

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

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

La parte final de la sección anterior sobre el bloqueo de proveedores destaca otro problema con el uso de un puente canónico de terceros: los emisores de tokens intercambian el control de los tokens puente canónicos a cambio de una mayor comodidad y mejoras en la experiencia del usuario. Para utilizar 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á controlado por LayerZero, que posee el contrato OFT que emite representaciones canónicas de BobToken en esas cadenas de bloques.

Si bien Bob podría esperar que LayerZero alinee las representaciones canónicas con el diseño original del token nativo, esto no siempre sucederá. En los peores escenarios, el comportamiento de BobToken en Ethereum puede diferir significativamente del de BobToken en Optimism porque 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 verse exacerbado por la dinámica principal-agente 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, donde 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 afecte 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 los fondos 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 → intercambiar 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 afecte al puente asociado es equivalente a la cantidad total de tokens que un atacante crea en cadenas remotas donde el puente afectado tiene una implementación. Esto es posible porque cada representación canónica en todas las cadenas se puede intercambiar 1:1 por tokens canónicos emitidos en otras cadenas:

Supongamos que un atacante compromete un puente de terceros en la cadena B y acuña 1000 tokens (donde el token se emite inicialmente en la cadena A) sin depositar garantías. Los tokens del atacante en la cadena B no están asignados al contrato de la cadena de origen, por lo que no puede retirarse de la cadena A. Aun así, puede hacer un puente a la cadena C e intercambiar 1000 tokens de la cadena B por 1000 tokens de la cadena C; recuerde, cada token entre cadenas es compatible y fungible ya que se originan en el mismo servicio de puente. Los tokens de la cadena C están asignados al contrato de la cadena de origen ya que fueron acuñados legítimamente por usuarios que bloquearon tokens en la cadena A (la cadena de origen del token), lo que permite 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 una CEX o una rampa de salida fiduciaria.

4. Pérdida de funciones de token personalizadas

Al utilizar un puente canónico de terceros, los emisores de tokens suelen perder la capacidad de implementar funciones 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 la funcionalidad especializada presente en la implementación del token original.

Las características comunes de los tokens, como la delegación de votos (ZK), los mecanismos de rebase (stETH, USDM), las capacidades de pago por transferencia (memecoins), las funciones de lista negra y lista blanca (USDT, USDC), las transferencias pausables y las reglas o permisos de acuñación especiales suelen eliminarse cuando los tokens se conectan a través de un proveedor externo, ya que la versión conectada normalmente utilizará una implementación ERC-20 básica. Esta pérdida de funcionalidad crea inconsistencias en la forma en que el token opera en diferentes cadenas y puede potencialmente romper las integraciones que dependen de estas características personalizadas.

La estandarización de tokens puenteados, 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 de mantener un comportamiento consistente del token en todo el ecosistema multicadena de su aplicación. Estos problemas pueden hacer que las expansiones entre cadenas sean una pesadilla para los desarrolladores y representar un obstáculo para hacer realidad el sueño de que las aplicaciones vivan en múltiples cadenas.

5. Cadenas con soporte limitado

Los emisores de tokens se vuelven dependientes de la cobertura de red y los planes de expansión del proveedor de puentes elegido. Si el proveedor de puentes no es compatible con una red de blockchain en particular a la que el emisor de tokens desea expandirse, se enfrenta a dos opciones poco óptimas:

• Espere a que el proveedor del 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 ZKsync Era que ha llevado a que muchas dapps nunca se implementen en él)
• 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 apoyo a cadenas populares y descuidar redes más pequeñas o nuevas que podrían ser estratégicamente importantes para el emisor de tokens.

6. Direcciones de tokens entre cadenas inconsistentes

Los proveedores de puentes externos pueden implementar tokens puenteados con diferentes direcciones en cada cadena debido a las peculiaridades de su pila tecnológica (por ejemplo, no son compatibles con CREATE2 ). La falta de coherencia de direcciones, a su vez, genera muchos problemas de experiencia del usuario:

• Riesgos de seguridad : los usuarios deben verificar diferentes direcciones de 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 token válidas para cada red;
• Mayor riesgo de phishing : los actores maliciosos pueden engañar más fácilmente a los usuarios con tokens falsos, ya que no existe una dirección consistente para verificar.

Estos inconvenientes, combinados con los problemas ya analizados de dependencia de proveedores, pérdida de soberanía y alta exposición a fallas de puentes, resaltan las limitaciones significativas de confiar en puentes canónicos de terceros para implementaciones de tokens entre cadenas. Esta comprensión ayuda a sentar las bases para explicar por qué se necesitan soluciones alternativas como ERC-7281 para abordar estos desafíos de una manera más integral.

3. Acuñar tokens canónicos a través de un puente entre el emisor y el token

Si un desarrollador desea mantener el máximo control de las implementaciones entre cadenas del token de un proyecto, puede gestionar 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 puenteada 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 de origen.

Para que ese enfoque funcione, el emisor de tokens debe configurar una infraestructura para gestionar la acuñación y la quema de tokens puenteados entre cadenas (al tiempo que garantiza que el suministro global se mantenga sincronizado mediante el mapeo canónico). Ejemplos notables de representaciones canónicas de un token emitido por el creador del token son Teleport de MakerDAO y Cross-Chain Transfer Protocol (CCTP) de Circle.

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 lenta. DAI se quema en una cadena y se acuña en la cadena de destino. CCTP funciona de manera similar y permite transferencias entre cadenas de USDC nativo (emitido por Circle) a través de un mecanismo de quema y acuñación. 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 puenteados para los protocolos y soluciona el problema de las representaciones no fungibles del mismo token de la manera más eficaz 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 todos los ecosistemas que el emisor del token admita.

Con este enfoque, las aplicaciones también se benefician de la eliminación de la fragmentación de liquidez causada por representaciones no oficiales y en puente de los tokens de un protocolo que flotan en el mismo ecosistema. Los desarrolladores también pueden crear aplicaciones entre cadenas más robustas (por ejemplo, intercambios entre cadenas y préstamos entre cadenas), ya que los puentes canónicos entre tokens y emisores permiten un movimiento de tokens entre cadenas eficiente en términos de capital, sin inconvenientes y seguro.

Sin embargo, la desventaja de los puentes canónicos entre tokens y emisores es que este modelo solo es viable para proyectos con suficiente capital para cubrir los gastos generales de implementar un token entre cadenas y mantener la infraestructura (oráculos, guardianes, etc.) necesaria para realizar la acuñación y quema entre cadenas. Esto también tiene el efecto un tanto indeseable de vincular estrechamente la seguridad de los activos puenteados con el modelo de seguridad del protocolo.

Esta relación (entre las versiones puenteadas 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 en el caso de los puentes de monedas estables operados por emisores como Circle y Maker (ahora Sky): los usuarios ya confían en que los emisores de monedas estables tienen suficientes activos para cubrir el canje de monedas estables por monedas fiduciarias, por lo que confiar en la seguridad de un puente de monedas estables no es difícil.

Pero también representa un punto central de falla: si la infraestructura puente del emisor de tokens se ve comprometida, el valor de todas las representaciones canónicas que circulan en el ecosistema multicadena 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 puente canónicos.

Reflexiones finales

Como se muestra en este informe, la fungibilidad de activos entre cadenas es una parte importante de la interoperabilidad de la acumulación, con implicaciones para la experiencia de moverse entre diferentes cadenas. La capacidad de los tokens de seguir siendo fungibles cuando se conectan a cadenas remotas también afecta la experiencia del desarrollador, ya que ciertos casos de uso dependen de esta característica.

Se han propuesto distintas soluciones para resolver el problema de los tokens infungibles entre cadenas, muchas de las cuales hemos abordado en este informe. Esto incluye la acuñación de tokens canónicos a través de puentes nativos (consagrados), el uso de un puente de terceros dedicado para acuñar tokens canónicos en múltiples cadenas y el uso de un puente propiedad del protocolo para facilitar el movimiento de tokens y preservar la fungibilidad.

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

ERC-7281 es un nuevo enfoque de fungibilidad de activos entre cadenas que mitiga las desventajas asociadas con los enfoques existentes. También conocido como xERC-20 , ERC-7281 permite que los protocolos implementen de manera eficiente tokens canónicos en múltiples cadenas sin sacrificar la seguridad, la soberanía o la experiencia del usuario.

El diseño exclusivo de ERC-7281 permite que varios puentes (incluidos en la lista blanca) acuñen versiones canónicas de los tokens de un protocolo en cada cadena compatible, al tiempo que permite a los desarrolladores de protocolos ajustar dinámicamente los límites de acuñación por puente. Esta característica resuelve muchos de los problemas asociados con las propuestas históricas de tokens canónicos multicadena, incluida la fragmentación de liquidez, la alineación de incentivos, las preocupaciones sobre la experiencia del usuario, los riesgos de seguridad de los puentes, la capacidad de personalización (de tokens entre cadenas) y más.

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

¡Manténganse al tanto!