Ya está lista nuestra actualización Amarok

La NEXT(😉) wave de desarrollo de dApps ya está entre nosotros.

Traducción del artículo “Connext’s Amarok Upgrade is Live” con fecha Feb 02, 2023.

Después de casi un año de R&D (Investigación y Desarrollo), estamos sumamente emocionados de anunciar que la actualización de Amarok de Connext ya está disponible públicamente. Esto significa que a partir de hoy:

1. La UI y el explorador de nuestro bridge usan exclusivamente la nueva red.
2. Los usuarios ya pueden ser Liquidity Providers Pasivos, tanto con USDC e ETH.
3. Cualquiera puede correr un Router para convertirse en un LP Activo en la red.
4. Los desarrolladores pueden crear cualquier tipo de aplicación crosschain libremente.

En este anuncio se explicará por qué existe Connext y esta actualización -Amarok-, cómo funciona el nuevo sistema, los supuestos de confianza y seguridad para los usuarios y cómo pueden participar los usuarios.

¡Empecemos! 🤿 🌊

Una actualidad fragmentada

Connext siempre tuvo una misión bastante sencilla:

Ayudar a llevar millones de usuarios a Ethereum.

Nuestra misión se basa en la creencia de que el sistema blockchain puede convertirse en la columna vertebral de una Internet más segura, justa y transparente, desbloqueando nuevas formas para que las personas se coordinen entre sí a escala mundial.

Escalar Ethereum para llegar a mil millones de usuarios implica trasladar usuarios, fondos y datos a múltiples dominios paralelos (sidechains, rollups y otras construcciones simil-chains). Esto, sin embargo, crea un nuevo reto: una experiencia de usuario fragmentada y multichain.

Tomemos, por ejemplo, el protocolo Aave. Cuando usamos Aave, experimentamos esta fragmentación de forma directa:

1. Cuando suministramos liquidez, lo hacemos en la red en la que nos encontramos, en lugar de hacerlo en la red que nos ofrece el mejor precio.
2. Cuando tomamos un préstamo, esa posición permanece en la red en donde tomamos ese préstamo. Migrar su posición a otra red conlleva un complejo proceso que implica repagar el préstamo, bridgear los fondos a otra chain y, a continuación, volver a crear la posición.

Este tipo de UX no es lo suficientemente buena para llegar a los mil millones de usuarios que deseamos. El usuario en general no desea manejar por sí mismo la complejidad de lo multichain. Incluso, en el mejor de los casos, ni siquiera quiere saber que está utilizando varias redes.

Un futuro Cross-Domain

Para superar las limitaciones de UX que existen hoy en día, tenemos que avanzar hacia aplicaciones nativas crosschain (xApps); aplicaciones que abstraen por completo el concepto de “red” para los usuarios, proporcionando en su lugar una experiencia única y sin complejidad que abarque la multiplicidad de redes existentes.

Una buena analogía de Web2 es Youtube.

Hoy, cuando buscamos vídeos de gatitos en Youtube, no necesitamos saber nada acerca de la compleja distribución de la infraestructura de la bases de datos de Google. Sólo se interactúa con la aplicación, que se encarga de todo ello en segundo plano.

De igual modo, las aplicaciones descentralizadas en el ecosistema necesitan abstraerse de las complejidades de interactuar con múltiples redes. Y del mismo modo que las aplicaciones web actuales interactúan de forma asincrónica con los recursos de Internet, las dApps deben interactuar de forma asincrónica con los usuarios, los fondos y los datos de esas múltiples redes.

¿Por qué aún no hemos llegado a ese punto?

Connext no es el único sistema que facilita el desarrollo de mensajería y aplicaciones crosschain (aunque sí es cierto que nuestros desarrolladores ya llevan mucho tiempo creando aplicaciones crosschain en Connext). Hay muchos otros puentes que permiten enviar fondos o pasar mensajes entre redes.

Donde estos fallan es en la seguridad y la minimización de la confianza. En los dos últimos años se han perdido miles de millones de dólares por hackeos en puentes:

Los desarrolladores están alarmados, y con razón. “Crosschain” es un tema difícil de entender y su comunicación se vuelve un campo minado de desinformación y publicidad engañosa difundida por los propios proyectos dedicados a este tipo de actividad. Además, lo crosschain conlleva un alto riesgo de catástrofe si se hace de forma incorrecta.

¿Entonces en qué podemos confiar?

¿Cuál es la infraestructura en la que podemos confiar? Esta es la pregunta clave que nos hicimos en Connext a la hora de desarrollar nuestra actualización del Amarok.

Nos dimos cuenta de que ya existe un ecosistema de puentes puestos a prueba en combate que aseguran todas las interacciones de los usuarios en cada red: los puentes canónicos. Algunos ejemplos son Optimism y Arbitrum Rollup Bridges, Polygon PoS Bridge, y GnosisChain Arbitrary Messaging Bridge.

Estos puentes ya son la base de la confianza para cada red. En el caso de los rollups, también son trust-minimized, y nótese que lo decimos en el sentido más estricto posible: no existe ningún sistema que proporcione una comunicación más segura dentro o fuera de una rollup que su propio puente nativo.

En los casos en los que no hay puentes canónicos, por ejemplo, para la comunicación L1-L1, también sabemos que los puentes light client (verificados por zk-SNARK) acabarán proporcionando la mejor seguridad posible. Hay muchos y equipos respetables trabajando en esto, como Succinct Labs, Overreality, zkIBC y Wormhole.

Entonces, en lugar de reinventar la rueda, decidimos apostar por las siguientes ideas:

1. El futuro se centrará en gran medida en las rollups.
2. Las implementaciones avanzadas de puentes light client zk acabarán existiendo como bienes públicos para las no-rollups.
3. Podemos minimizar el riesgo para los usuarios conectándonos a puentes canónicos de eficacia demostrada para transportar y proteger los mensajes, en lugar de crear un nuevo sistema desde cero.

Interoperabilidad modular

Connext es el primer puente de ejecución modular que permite una comunicación trust-minimized entre dominios (redes y rollups) mediante la transmisión optimista de datos y el respaldo en la seguridad de los puentes canónicos.

Cada mensaje crosschain que pasa por Connext viaja primero hacia Ethereum L1, en un sistema hub-and-spoke:

Los mensajes en Connext se añaden a un Merkle root en cada red, se transmiten a Ethereum L1, se agregan a un Merkle root combinado ahí (agregador), y luego se retransmiten nuevamente a todas las demás redes. Este proceso se realiza en gran medida de forma offchain por el secuenciador de Connext, con la data availability del agregador de roots garantizado en L1 por los puentes canónicos.

Aquellos que presten mayor atención se darán cuenta de algo interesante:

Este modelo convierte a Connext en una Rollup Optimista (específica para cada aplicación), diseñada para sincronizar el estado de otras rollups.

Hay MUCHOS más detalles técnicos sobre el funcionamiento de Connext que quedan fuera del alcance de este post. Pronto publicaremos un artículo técnico en el que explicaremos cómo funciona y se integra el sistema.

Supuestos de confianza y seguridad

Uno de nuestros valores fundamentales como proyecto es la total transparencia e integridad. En este sentido, tenemos una larga tradición de exponer los supuestos de confianza y centralización de nuestro sistema en cada publicación sobre un lanzamiento.

Suposición Central: dependencia del puente canónico subyacente

Las disputas dentro de Connext son resueltas por el puente canónico de cada red. Si se observa fraude en el sistema, éste recurrirá a dicho puente. Para los sistemas trustless, como las rollups, esto ofrece la mayor seguridad posible, ya que para que un fraude pudiera pasar a través de Connext sería necesario un fallo del sistema Connext Watcher y un fraude por parte del secuenciador de la Rollup.

Sin embargo, para las redes en las que no se dispone de un puente canónico o trust-minimized, lo mejor que puede hacer Connext es heredar las propiedades de seguridad del puente subyacente, y resolver el posible fraude exige una acción manual por parte del admin del protocolo de Connext. El principal caso en el que esto es relevante actualmente es BNB Chain, en la que Connext utiliza actualmente Multichain para transportar y verificar mensajes. Sin embargo, ya está previsto y existen planes para implementar un light client de verificación zk (zero-knowledge) para esa red lo antes posible.

Capacidad de ser actualizado

Históricamente hemos evitado la capacidad de actualización a nivel protocolo. Sin embargo, dada la nueva naturaleza modular de Connext y nuestro interés por ofrecer la mejor experiencia posible a los desarrolladores, hemos decidido en esta instancia avanzar hacia una “actualizabilidad” controlada por DAO.

Al momento del lanzamiento, el protocolo está controlado por una multisig 3-de-3 para simplificar la configuración. En las próximas dos semanas, el plan es ampliar esto a un multisig 5-de-7, Por último, se transferirá la propiedad a la DAO tan pronto como se lance el token NEXT. La mayor parte de la funcionalidad de administración está sujeta a un timelock de una semana, con el objetivo de pasar todo a un formato de timelock estándar para cuando se lance la DAO.

Número de watchers limitado en el lanzamiento

Los Watchers en Connext son responsables de (1) monitorear los mensajes que se pasan de forma optimista entre redes, (2) monitorear los puentes canónicos subyacentes, (3) pausar el sistema si detectan un problema con cualquiera de los anteriores.

En su lanzamiento, Connext tiene una whitelist de Watchers y sólo 1 Watcher es administrado por el Core Team, estando activo y monitoreando mainnet. Tenemos previsto ampliar este número en las próximas dos semanas para incluir otros tres Watchers gestionados por DeFi Wonderland, P2P y Bware Labs. Una vez que el token NEXT esté activo y se introduzca el staking/slashing en la red, el sistema de monitoreo se convertirá en permissionless, y los Watchers formarán, por defecto, parte del stack de routers de Connext.

Supuesto de confianza en el Relayer para el pago de fees

Cuando los usuarios realizan transacciones en la red, abonan fees adicionales en la red de origen para pagar a los Relayers que ejecutan sus transacciones en la de destino. La forma en que se contabiliza este mecanismo es segura para el usuario, pero es completamente trusted para Connext, ya que Connext Labs adelanta las fees a la red de relayers (Gelato), y es reembolsado por los usuarios.

Se trata de un supuesto de confianza totalmente aceptable, ya que sólo afecta a Connext Labs. Esta suposición existe porque algunas redes aún no implementan el código de operación BASEFEE. Una vez que éstas añadan soporte para EIP1559, esta asunción se podrá hacer de forma trustless (y podremos añadir soporte para reembolsar el gas no utilizado por los usuarios 😄).

Censura/MEV/Riesgo de inactividad del Sequencer

El sistema de routers de Connext está totalmente descentralizado: ya hay 8 Routers en funcionamiento, más de 30 ya han migrado desde la versión anterior y cientos participaron en la testnet o se inscribieron en nuestra lista de espera el año pasado.
La censura de una transacción individual de un usuario es imposible, ya que basta con que un único Router esté dispuesto a enrutar un transacción para que ésta se transmita. Hay que tener en cuenta que, en este momento, los routers están sujetos a una whitelist, pero esto es sólo para detener el frontrunning por MEV bots en la mempool (cosa que empeoraría la experiencia de usario significativamente).

Por otra parte, en este momento, la secuenciación está centralizada en Connext. El Sequencer de Connext (gestionado por Connext Labs) tiene la capacidad de ordenar/seleccionar transacciones, lo que podría suponer una pérdida de ingresos por fees de los routers si se hiciera de forma injusta. Además, el tiempo de inactividad del Sequencer podría provocar una paralización generalizada de la red.

Tanto la whitelist de routers como la secuenciación centralizada pueden solucionarse posteriormente y como consecuencia del staking/slashing del token NEXT dentro del protocolo.

Consideraciones de seguridad

El protocolo ya ha sido auditado 4 veces, con revisiones de seguridad adicionales y verificaciones formales previstas para el futuro. También hay un bounty de seguridad activo en Immunefi.

¿Cómo participar?

Ahora que Amarok está disponible, hay varias formas de empezar a interactuar con la red:

• Utilizar el puente de Connext para transferir fondos entre redes compatibles.
• Aportar liquidez a las pools de Connext.
• Ejecutar un router para ayudar a operar la red y ganar comisiones.
• Crear una xApp.
• Involucrarse en nuestra comunidad.

Acerca de Connext

Connext es una red para comunicación rápida y trustless entre redes y rollups. Es el único sistema de interoperabilidad de su especie que hace esto de forma económica y rápida sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente crosschain. Hasta la fecha más de $1500 millones de USD en transacciones han cruzado la red.

Website | Docs | Twitter | Discord | Github | Telegram | Crosschain Bridge