Actualice su dApp a xChain
Connext permite a los desarrolladores construir dApps xChain (xApps) seguras. Nuestra red es la única forma de crear xApps que conservan la seguridad de las blockchains subyacentes.
xApps (se pronuncia “zaps”) son aplicaciones descentralizadas que realizan operaciones entre cadenas/entornos de ejecución independientes, Ethereum y Avalanche, Polygon y Polkadot, y también Optimism y Arbitrum, por ejemplo.
https://twitter.com/ConnextNetwork/status/1498650721004236801?s=20&t=Aq3Kc82riklbelrmPzwclQ
Los desarrollos multichain ya están aquí. Aave, Yearn, Curve, todos tienen múltiples interfaces en muchas redes.
Si bien uno puede usar todas estas aplicaciones en diferentes cadenas, éstas actúan como aplicaciones diferentes separadas entre sí: son multichain, no xChain.
Entonces, ¿cómo se construye un paradigma xChain?
Interfaz unificada: cree una interfaz que agregue datos de todas las cadenas y muestre a los usuarios una única experiencia consolidada.
Abstraer la “home” chain: reconozca los saldos y las acciones de los usuarios de cualquier cadena soportada, independientemente de dónde el usuario inicie sus interacciones.
xCall para enrutar transacciones a cualquier cadena: use Connext para permitir que los usuarios llamen a cualquier contrato en la red de recepción en un solo paso, o incluso para conectar directamente sus contratos entre sí.
El resultado final ideal es una xApp que tenga una única interfaz que permita a los usuarios acceder a liquidez o datos de cualquier cadena. ¡Los usuarios nunca deberían preocuparse en qué cadena están si no quieren!
Aquí hay algunas ideas:
xChain zaps: similar a las aplicaciones LP, el usuario tiene un activo en una cadena, lo transfiere a una farm en otra cadena donde puede dividir su activo en el LP y luego depositarlo directamente, todo abstraído del usuario.
Gobernanza xChain: si el usuario cuenta con tokens de gobernanza que se han bridgeado a una cadena que no es la nativa de la dApp, no puede votar. La votación xChain será el estándar para los protocolos de gobernanza y las DAO.
Optimización del yield CrossChain: enviar tokens a otras redes, cosechar, y recolectar las ganancias.
Arbitrajes entre DEXs: una oportunidad para que los arbitrajistas entre DEXs se luzcan y se beneficien de los diferentes precios del mercado en todas las cadenas.
Préstamos xChain: agregar colateral en la cadena A, tomar prestado otro activo en la cadena B.
https://twitter.com/lifiprotocol/status/1504391836999290885?s=20&t=MLGgtxUeeW_82PZrQTihPw
Apenas hemos comenzado a ver la superficie de lo que podemos hacer con las operaciones xChain.
Construir dApps ya es bastante difícil. Cuando se añaden más cadenas, todo, como implementar contratos, administrar direcciones de contratos, leer y escribir el estado, administrar proveedores/nodos RPC, aumenta exponencialmente la complejidad para los builders y usuarios.
Connext simplifica la experiencia de crear aplicaciones cross chain, con el más alto nivel de seguridad:
Una interfaz de contrato inteligente unificada para xApps nativas. Puede usar Connext para elegir con precisión qué operaciones de cross-chain desea realizar; una sola interfaz unificada para reducir las complejidades del desarrollo.
Bridge de liquidez instantáneo y calldata passing. Esto le permite abstraer la interfaz de gas del usuario al permitir que el protocolo llame a la función en la cadena de recepción.
Message passing: paso de mensajes unidireccional y bidireccional.
https://twitter.com/ConnextNetwork/status/1505256394244636674?s=20&t=RmmohtJpFLE4OHzVPtM81w
El paso de mensajes unidireccional significa que puede pasar un mensaje de manera trustless de una cadena a otra y verificar que proviene de una fuente específica. Si desea votar de una cadena a otra, puede hacerlo de manera confiable.
Bidireccional, si necesita enviar un request a una cadena (por ejemplo, leer un precio TWAP) y luego obtener un resultado en la cadena original.
Las xApps son parte de la nueva ola de innovación y el futuro estándar para cualquier dApp.
Ya sea que escriba contratos inteligentes o use el SDK de Connext en entornos web/Node, la construcción de una xApp para realizar operaciones CrossChain finalmente se reduce a comprender un conjunto de parámetros estándar para enviar calls cross-chain ("xcalls"). Esta es una introducción rápida sobre cómo construir los parámetros necesarios para xcall.
La xcall function toma un solo argumento XCallArgs:
Volveremos a hablar de CallParams en un momento; comencemos con los demás.
transactingAssetId: se refiere a la dirección del contrato del activo que se pretende bridgear. Esto incluye cualquier token compatible con ERC-20. Por lo general, una xApp tendrá una función de nivel superior que envuelve xcall en la que la dirección del activo se pasará como un argumento para permitir que el usuario especifique con qué activo desea trabajar.
amount: la cantidad de tokens a transferir especificados en formato estándar (es decir, para enviar 1 USDC, un token con 18 decimales, debe especificar la cantidad como 10000000000000000000).
relayerFee: este es un fee que se paga a los relayers por transmitir la transacción al otro dominio. En la testnet Connext Amarok, esto se puede establecer en 0 porque los relayers en la testnet no cobran ningún fee. Sin embargo, en mainnet, este valor debe ser lo suficientemente alto para satisfacer las condiciones de costo de los relayers para retransmitir una transacción, que incluye el gas fee y un poco más como incentivo. Este fee se paga en el activo nativo del dominio de origen, está bloqueado en el dominio de origen y finalmente es reclamado por el relayer. Los contratos de Connext afirmarán que relayerFee coincide con lo que se envía en msg.value para xcall*.* Si, por alguna razón, el relayerFee es demasiado bajo, BridgeFacet.bumpTransfer puede ser llamado en el dominio de origen para aumentar el fee inicial hasta que sea suficiente para los relayers.
El argumento restante es CallParams.
to: se refiere a una dirección en la cadena de destino. Ya sea la dirección de la wallet de un usuario o la dirección de otro contrato, depende del uso deseado de xcall. Si xcall está destinado simplemente a cruzar fondos, entonces el usuario debería poder especificar esto como su propia wallet o tal vez otra dirección en la cadena de destino. Si xcall está destinado a enviar calldata arbitraria a un contrato de destino, entonces esta dirección debe ser la dirección de ese contrato.
callData: sólo en el caso de cruzar fondos debe estar vacío. Si se va a enviar calldata arbitraria, se deben pasar aquí la calldata codificada.
originDomain / destinationDomain: estos se refieren a los domain IDs que son mapeados por Nomad. Estos ID de dominio no son equivalentes a los "ID de cadena".
recovery: una dirección de recuperación en el lado de destino para enviar fondos si la ejecución falla. Esto garantiza que los fondos enviados con calls fallidas sigan siendo accesibles.
callback: la dirección de un contrato que implementa la interfaz ICallback. Si el contrato de destino no devuelve nada, este campo debe ser la dirección cero. Consulte las especificaciones detalladas para la interacción de callback.
callbackFee: similar a relayerFee excepto que esto es para pagar a los relayers en la ejecución de callback. Nuevamente, esto se puede establecer en 0 en la testnet de Connext Amarok. ¡Esta fee también se puede cambiar desde el dominio de origen!
forceSlow: establecer esto en true permite a los usuarios forzar la xcall a través de Nomad slow path (~30 minutos) y ahorrar en el fee de transacción del 0,05% que cobran los routers. Tenga en cuenta que esto solo tiene un efecto en las transferencias fast path, ya que las llamadas slow path xcalls pasarán a través de la ruta lenta independientemente. Esta es simplemente una opción para los usuarios que no se preocupan por la velocidad para optimizar el costo.
receiveLocal: establecer esto en true permite a los usuarios recibir el activo local de Nomad en lugar del activo adoptado en el dominio de destino.
Armado con este conocimiento, puede escribir un conjunto de contratos inteligentes simples que envían calldata desde ChainA para que se ejecuten en ChainB. La interfaz ICallback también se puede implementar para reaccionar de forma asincrónica a los resultados de ejecución de ChainB en ChainA.
Source.sol
Target.sol
Con el ejemplo anterior, la función doSomething del contrato Target.sol debe ser permissioned. En otras palabras, solo queremos que el contrato de origen (Source.sol*)* pueda llamar a la función de destino. Es por eso que se deben realizar las verificaciones de originSender() y origin(), para cumplir con el requisito de autorización. El contrato Source.sol también demuestra el uso de callbacks donde los resultados de ejecución en diferentes dominios se pueden manejar de forma asincrónica.
Hay varias formas de usar xcall, desde enviar calldata autorizada CrossChain (como arriba) o simplemente transferir fondos. Connext hace que la construcción de aplicaciones CrossChain sea actualmente mucho más accesible para los desarrolladores, al mismo tiempo que mantiene el enfoque en la experiencia y la seguridad del usuario final.
El Trilema de Interoperabilidad y Puentes Optimistas, nuestro modelo de seguridad
¿Qué es Modular Interoperability Stack? Revisa la presentación de Layne
Entra en nuestro Discord, ponte en contacto con el equipo y otros builders
¿Trabajando en una idea genial? Solicitar un grant
Connext es una red para comunicación rápida y trustless entre cadenas y rollups. Es el único sistema de interoperabilidad de su especie que hace esto de manera económica y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir bridges y otras aplicaciones nativamente CrossChain. Hasta la fecha más de $1500 millones de USD en transacciones han cruzado la red.
Website | Documentation | Twitter | Discord | Github | Blog | Telegram