Avalanche Interchain Token Transfer

by MICHELLE TIAN

Con la introducción de cadenas sin permisos, ahora nos referiremos a las “Subnets” como “L1s”.

Resumen

Ava Labs presenta Avalanche Interchain Token Transfer (Avalanche ICTT), una solución segura y eficiente para que cualquier desarrollador despliegue contratos para transferir tokens en Avalanche. Esta innovación simplifica el proceso tradicionalmente complejo y costoso de crear y auditar contratos inteligentes para el envío de tokens entre blockchains de Capa 1 (L1). Con contratos inteligentes preconstruidos, minuciosamente auditados y sin permisos, Avalanche ICTT permite el envío sin dificultades de tokens como USDC y BTC entre varias L1s en Avalanche. Esta mejora ahorra tiempo y recursos, a la vez que garantiza seguridad y estandarización en las transacciones entre cadenas.

Introducción: El Problema de los Bridges

En el mundo en evolución de la tecnología blockchain, la comunicación fluida entre diferentes redes blockchain es esencial. Ahí es donde entra en juego Teleporter, un protocolo de comunicación entre cadenas de última generación diseñado para permitir que las L1 de Avalanche (anteriormente conocidas como Subnets) intercambien información sin esfuerzo, similar a cómo los países comercian y se comunican.

Pero Teleporter en sí mismo es solo la base para la comunicación entre cadenas. No incluye lógica incorporada adaptada para aplicaciones específicas. Por ejemplo, para transferir tokens entre L1s en Avalanche, generalmente necesitas contratar ingenieros de Solidity, hacer que escriban los contratos inteligentes necesarios y luego encontrar un auditor para auditar estos contratos. Este proceso es costoso y lleva mucho tiempo, a menudo varios meses. Además, los puentes tradicionales suelen estar llenos de asunciones adicionales de confianza, no son transparentes ni abiertos por diseño y tienen puntos centrales de fallo.

Para hacerlo más concreto, aquí hay algunos ejemplos de cosas que podrías querer hacer y por qué son difíciles:

• Quieres USDC en tu L1, pero para hacerlo se requiere una asociación con Circle, lo que puede llevar tiempo y recursos.
• Quieres BTC en múltiples L1s en Avalanche, pero esto requiere que cada una de estas L1s coordine, acuerde un proceso estándar de puenteo y luego encuentre un proveedor externo para implementar los contratos.
• Quieres personalizar tu L1 usando tu propio ERC-20 como el token de gas. Esto requiere asociarse con un proveedor de puentes externo, lo que tomará tiempo, dinero, recursos de ingeniería y suposiciones adicionales de confianza.
• Para mejorar la experiencia del desarrollador y agilizar este proceso, Ava Labs ha desarrollado una solución integral.

La Solución: Avalanche Interchain Token Transfer

Avalanche Interchain Token Transfer (Avalanche ICTT) supera los inconvenientes tradicionales de los puentes aprovechando la tecnología subyacente de Teleporter y Avalanche Warp Messaging. Avalanche ICTT NO depende de un pequeño subconjunto de nodos, un operador central ni una multisig para su funcionamiento. En cambio, utiliza el conjunto de validadores de la blockchain L1 de origen, que puede consistir en un número ilimitado de validadores. A diferencia de otras soluciones de puenteo de terceros, Avalanche ICTT NO introduce suposiciones adicionales de confianza: los validadores de la L1 son suficientes.

Además, Avalanche ICTT simplifica y acelera las transferencias de tokens entre cadenas al reducir las complejidades y demoras típicamente asociadas con la puesta en marcha: hemos desarrollado y auditado contratos inteligentes esenciales, asegurando que sean seguros y listos para usar. Esto significa que puedes concentrarte en lo que más importa: construir e innovar, mientras que Avalanche ICTT maneja las complejidades de la comunicación entre cadenas.

Con Avalanche ICTT, obtienes:

• Accesibilidad: Cualquiera puede desplegar estos contratos: son completamente sin permisos y abiertos por diseño.
• Eficiencia de Costos: No es necesario invertir en extensos procesos de desarrollo y auditoría.
• Ahorro de Tiempo: Acelera los tiempos de tu proyecto con contratos inteligentes listos para usar.
• Seguridad: Apoyate en contratos minuciosamente auditados para garantizar que tus transferencias de tokens sean seguras. A diferencia de los puentes tradicionales, no se introducen suposiciones adicionales de confianza.

Varias L1s existentes y nuevas pronto estarán integrando Avalanche ICTT a través de AvaCloud. Entre los partners de lanzamiento se encuentran nombres prominentes como Lamina1, GoGoPool y ZeroOne. Experimenta la facilidad y eficiencia del envío de tokens entre cadenas con Avalanche ICTT y desbloquea nuevas posibilidades para tus proyectos en Avalanche.

Cómo Funciona: Descripción Técnica

El contrato Avalanche ICTT no es actualizable, lo que proporciona inmutabilidad y asegura que el comportamiento del contrato en cada dirección no cambie. La interfaz proporciona un proceso simple y estándar para transferir un token ERC-20 o un token Nativo (token utilizado para pagar las tarifas de transacción en la cadena dada) de una cadena de origen a una cadena de destino, donde se representa como un nuevo token. Esta representación de token en la cadena de destino puede ser un token ERC-20 o Nativo, permitiendo a los usuarios tener cualquier combinación de ERC-20s y tokens Nativos entre cadenas de origen y destino:

ERC-20 <> ERC-20
ERC-20 <> Nativo
Nativo <> ERC-20
Nativo <> Nativo

Los contratos permiten implementar lógica personalizada para la acuñación, quema o transferencia personalizada. Como se indica en el repositorio, el contrato de origen se conoce como el contrato “Home”, y el contrato de destino se conoce como el contrato “Remote”, por lo que usaremos estos términos en adelante.

Algunos conceptos clave para entender:

1. Un solo contrato “Home” puede tener múltiples contratos “Remote”.
2. Un contrato “Remote” solo interactúa con un solo contrato “Home”.
3. Cada combinación de contratos se define por activo.
4. Cada L1 puede tener múltiples contratos de transferencia de tokens independientes desplegados.

Los ejemplos a continuación ilustran cada uno de los conceptos anteriores:

1. Un solo contrato “Home” de USDC en Avalanche C-Chain puede conectarse a múltiples contratos “Remote” de USDC en varias L1s. Los contratos “Remote” pueden transferir el USDC como un ERC-20 o como el token de gas Nativo de esa L1.
2. Un solo contrato “Home” mantiene el colateral para un contrato “Remote” dado. El contrato “Remote” tiene exactamente un “Home”.
3. Contratos “Home” y “Remote” separados para diferentes tokens, por ejemplo, USDC y AVAX tienen sus propios conjuntos.
4. Dado que cualquiera puede desplegar estos contratos, puede haber múltiples contratos para cualquier token en una L1. Para evitar la fragmentación, las L1s pueden habilitar el Contract Manager Precompile para restringir quién puede desplegar contratos en la L1.

Para empezar con Avalanche ICTT, consulta el Avalanche Starter-Kit, el curso de Avalanche Academy o despliega tu propio contrato de transferencia de tokens en el CLI de Avalanche siguiendo las instrucciones. Para un enfoque sin código, las L1s pueden dirigirse a AvaCloud y consultar sobre interoperabilidad.

Casos de Uso y Flujos de Ejemplo

¿Quieres entender más sobre el flujo de extremo a extremo? Vamos a recorrer un ejemplo de ERC-20 <> ERC-20 para el puenteo de USDC nativo en Avalanche C-Chain a una L1.

1. Despliega el contrato “Home” de ERC-20 en C-Chain, especificado para USDC como el activo.
2. Despliega el contrato “Remote” de ERC-20 en la L1 deseada, especificado para USDC y mapeado al contrato “Home”.
3. Para transferir USDC de C-Chain a la L1:
   - El USDC primero se envía al contrato “Home” en C-Chain, donde el USDC se bloquea en este contrato como colateral.
   - En una segunda transacción, el contrato “Remote” acuña la cantidad equivalente de USDC en la L1.
4. Para redimir el USDC de vuelta a C-Chain, el USDC envuelto en la L1 se quema por el contrato “Remote”, luego una segunda transacción libera el USDC bloqueado en el contrato “Home” en C-Chain.

Ahora vamos a recorrer un ejemplo de ERC-20 <> Token Nativo para desplegar USDC como el token de gas Nativo de una L1.

1. En lugar de desplegar un nuevo contrato “Home” de USDC en C-Chain, se puede reutilizar el que se desplegó en el paso 1 del ejemplo anterior. Recuerda que un solo contrato de origen puede tener múltiples contratos de destino.
2. Obtener USDC como el token de gas nativo de esta L1 es un problema de huevo y gallina, ya que alguna cantidad de tokens Nativos debe existir para pagar los costos de gas para 1) desplegar el contrato “Remote” de USDC y 2) acuñar el USDC transferido de C-Chain. Para solucionar esto, primero preasigna la L1 con algo de USDC enviándole un airdrop en el génesis. Este USDC es efectivamente sin valor en este punto porque aún no está colateralizado.
3. Ahora que la L1 tiene el airdrop de USDC, es decir, alguna representación de gas, se puede desplegar el contrato “Remote” de Token Nativo en la L1. Como recordatorio, asegúrate de mapear al contrato “Home” correcto al desplegar el contrato “Remote”.
4. El último paso es colateralizar el contrato “Home” en C-Chain enviándole suficiente USDC para igualar 1:1 el USDC acuñado en la L1 en el contrato “Remote”. Nota: Hasta que los contratos estén colateralizados, no se pueden acuñar nuevos tokens en el destino.
5. Ahora que los contratos están configurados correctamente, se puede acuñar USDC en la L1 con el Native Minter Precompile. Este precompile es simple: proporciona al contrato “Remote” la capacidad de acuñar tokens Nativos y enviarlos a una dirección de destinatario designada. El contrato “Remote” contiene lógica para asegurar que a partir de ahora, la cantidad de tokens acuñados en el lado del destino (L1) sea igual o menor al USDC colateralizado en el origen (C-Chain).

Otro escenario que vale la pena explorar es el caso de multihop, en el cual se transfiere USDC entre dos L1s diferentes, ninguna de las cuales es la “cadena de origen” para USDC.

1. Primero, se deben desplegar contratos “Remote” de USDC en ambas cadenas — llamémoslas L1a y L1b — que están mapeadas al mismo contrato “Home” de USDC en C-Chain.
2. Dado que USDC no es nativo de ninguna de las L1s, se necesita un multihop, lo que significa que hay 3 transacciones en lugar de las típicas 2:
   - El USDC primero se quema en L1a. Se envía un mensaje (notificación) a la cadena de origen del token (en este caso, C-Chain).
   - C-Chain lleva un registro de los saldos de USDC a través de L1s en su “libro de contabilidad” y luego envía un mensaje a L1b para acuñar el USDC equivalente.
   - L1b acuña la cantidad equivalente de USDC.

El principal beneficio de este diseño es la seguridad y la eficiencia: los contratos de destino solo necesitan confiar en el contrato de origen, y ningún activo se envuelve más de una vez. Si L1a fuera hackeada, no puede afectar los saldos en otro destino (por ejemplo, L1b), ya que el contrato de origen siempre lleva un registro de cuánto saldo tiene cada contrato de destino. Ningún activo se envuelve más de una vez porque el número máximo de transacciones necesarias para cualquier token transferido es 3.

Contenido Adicional: Funciones Avanzadas

Una característica interesante incluida en los contratos es la capacidad de usar los tokens transferidos en una interacción de contrato inteligente dentro de un solo mensaje de Teleporter. Esta característica, conocida como sendAndCall, disminuye el número de interacciones del usuario.

Por ejemplo, digamos que estás en C-Chain pero quieres estar en L1. Actualmente tienes AVAX pero finalmente quieres USDC para poder interactuar con la dApp en L1. Tradicionalmente, tu flujo de trabajo sería algo así:

• Transferir AVAX de C-Chain a L1
• Intercambiar AVAX en C-Chain por USDC en L1
• Interactuar con la dApp en L1 con USDC

sendAndCall agrupa estos pasos en uno, mejorando la experiencia del usuario y facilitando el aprovechamiento de los servicios en la cadena de destino, ya que cualquier contrato puede ser llamado. Lo hace al darle permiso a un contrato designado para gastar una parte de tu AVAX para que puedas realizar el intercambio y enviar los fondos a la dApp deseada, eliminando la necesidad de múltiples transacciones separadas.

Notas Importantes

• sendAndCall tiene un mecanismo de respaldo donde, si la interacción del contrato inteligente falla por cualquier motivo, los tokens aún completarán una operación de puenteo regular, pero los activos se transferirán a la dirección de destinatario especificada por el usuario. El contrato inteligente para el servicio no tendría los tokens ni podría gastarlos ya que la interacción falló.
• Aún se necesita un relayer para entregar tokens entre estas L1s. Puedes aprender más sobre la configuración de un relayer aquí, o dirigirte a AvaCloud para tener un servicio de Relayer Administrado.
• Los contratos de Avalanche ICTT no son actualizables y no pueden ser cambiados una vez desplegados. Esto proporciona inmutabilidad a los contratos y asegura que el comportamiento del contrato en cada dirección no cambie.
• De manera similar, Teleporter Messenger no es actualizable, pero se pueden desplegar y rastrear nuevas versiones a través del Teleporter Registry, que proporciona a las aplicaciones que utilizan una instancia de Teleporter Messenger un proceso mínimo para integrarse con nuevas versiones de Teleporter Messenger. Nota: las nuevas versiones se registran a través de mensajes de Warp fuera de la cadena, lo que hace que el Registro sea una operación distribuida.
• Por defecto, los contratos de Avalanche ICTT envían mensajes de Teleporter utilizando la última versión disponible en el Registro de Teleporter en cada cadena. Además, hay un rol de administrador de Teleporter Manager que puede elegir una versión mínima soportada del contrato de Teleporter Messenger. Este administrador también tiene la capacidad de pausar el contrato de transferencia de tokens pausando ciertas direcciones de Teleporter Messenger.
• Es importante notar que el Teleporter Manager puede ser configurado para cualquier cosa. Para evitar cualquier tipo de funcionalidad de administrador por completo, se podría configurar como “sin dueño” (es decir, 0x00..01). Sin embargo, la mayoría considerará esta característica útil cuando haya nuevas versiones de Teleporter Messenger. Como tal, puede configurarse para un solo EOA, un contrato multisig o incluso un contrato que utilice mensajes de Warp fuera de la cadena para autenticación (haciéndolo tan distribuido como el conjunto de validadores de la L1 en la que está). El compromiso es la rapidez para actuar en caso de una vulnerabilidad versus el control centralizado del contrato. Es configurable, y se puede elegir cualquier punto a lo largo de esa curva para los requisitos de un caso de uso dado.

Conclusión

Avalanche ICTT representa un avance significativo en la comunicación entre cadenas utilizando el protocolo Teleporter. Al eliminar la necesidad de extensos procesos de desarrollo y auditoría, proporciona una forma simplificada, rentable y segura de gestionar transferencias de tokens entre diferentes L1s dentro de Avalanche.

Con su diseño sin permisos, inmutabilidad y conjunto completo de características, Avalanche ICTT empodera a los desarrolladores para que se concentren en la innovación mientras aseguran la integridad y seguridad de sus proyectos.

Ya sea que estés buscando transferir tokens ERC-20, utilizar tokens Nativos o explorar características avanzadas como sendAndCall, Avalanche ICTT abre un mundo de posibilidades para tus aplicaciones blockchain.

Este artículo es una traducción al idioma español del siguiente artículo publicado en inglés por Michelle Tian