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.

¿Qué son las xApps?

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

De multichain a xChain

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!

¿Qué se puede construir?

Aquí hay algunas ideas:

1. 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.

2. 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.

3. Optimización del yield CrossChain: enviar tokens a otras redes, cosechar, y recolectar las ganancias.

4. 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.

5. 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.

Construya xApps con Connext

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:

1. 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.

2. 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.

3. 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.

Entonces, ¿Cómo se construye una xApp?

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.

Recursos

• El Trilema de Interoperabilidad y Puentes Optimistas, nuestro modelo de seguridad

• ¿Qué es Modular Interoperability Stack? Revisa la presentación de Layne

• Kit de inicio para xApps (+ docs )

• Entra en nuestro Discord, ponte en contacto con el equipo y otros builders

• ¿Trabajando en una idea genial? Solicitar un grant

Acerca de Connext

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

Hace unos meses lanzamos NXTP, nuestro protocolo que habilita transferencias y llamadas de contratos entre dominios (dominios = cadenas y L2s) Ethereum-compatibles completamente trustless (que no requieren confiar en nadie más que en los validadores de las cadenas subyacentes).

https://twitter.com/ConnextNetwork/status/1442846763841425410?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1442846763841425410%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3Dhttps3A%2F%2Ftwitter.com%2Fconnextnetwork%2Fstatus%2F1442846763841425410image%3Dhttps3A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fabs.twimg.com252Ferrors252Flogo46x38.png26key3Da19fcc184b9711e1b4764040d3dc5c07

Este post intentará explicar por qué la interoperabilidad entre dominios de Ethereum es difícil, y desde ahí mostrar por qué creemos que NXTP representa el comienzo de una verdadera solución de largo plazo para el ecosistema.

La Necesidad de Interoperabilidad Trustless en Ethereum

Ethereum multicadena/L2 está aquí y llegó para quedarse. Esto ha estimulado la creación de decenas de puentes nuevos y protocolos de interoperabilidad mientras los proyectos se apuran para permitir esta funcionalidad en DeFi.

Como es de esperar, también ha traído un número de hackeos y estafas de alto perfil:

• Los múltiples hackeos de Thorchain.

• El hackeo de PolyNetwork.

• Esta joya absoluta:

https://twitter.com/dberenzon/status/1431337257873465344?s=20&t=sfeendtONrVjdN2_qbxd6Q

A pesar de estos ejemplos, todos los sistemas de bridging que existen se proclaman a sí mismos como trustless, seguros, y descentralizados (incluso si ese no es el caso en absoluto). Esto significa que el gran desafío para los desarrolladores y los usuarios ahora es: “¿cómo puedo descifrar cuáles mecanismos de bridging son en verdad cryptoeconómicamente seguros?”

En otras palabras, cómo pueden los usuarios discernir entre distintos tipos de puentes para determinar en quién están confiando cuando mueven fondos entre cadenas?

¿Qué Significa “Trustless” en Cryptoeconomía?

En la comunidad de investigación, cuando hablamos de seguridad cryptoeconómica y la propiedad de ser trustless, en realidad nos hacemos una pregunta muy específica:

¿Quiénes están verificando el sistema y cuánto cuesta corromperlo?

Si nuestro objetivo es construir bienes públicos realmente descentralizados e incensurables, entonces debemos considerar que nuestros sistemas podrían ser atacados por adversarios increíblemente poderosos como naciones soberanas rebeldes, megacorporaciones, o genios malvados megalomaníacos.

Maximizar la seguridad significa maximizar el número y la diversidad de los verificadores (validadores, mineros, etc.) en tu sistema, y esto típicamente significa hacer tu mejor esfuerzo para tener un sistema que es verificado enteramente por el conjunto de validadores de Ethereum. Esta es la idea central detrás de L2 y el enfoque de escalabilidad de Ethereum.

*Aparte: la mayoría de las personas no se da cuenta de esto, pero la investigación de escalabilidad es investigación de interoperabilidad. Hemos sabido que podemos escalar moviéndonos a múltiples dominios por mucho tiempo. El problema siempre ha sido cómo habilitar la comunicación hacia estos dominios de manera trustless. Es por eso que el artículo seminal de John Adler sobre optimistic rollups se titula “Puentes bidireccionales trustless con sidechains por detención”.*

Qué Ocurre si Añadimos Nuevos Verificadores entre Dominios?

Tomemos lo que hemos aprendido arriba acerca de la seguridad cryptoeconómica y apliquémoslo a los puentes.

Considere un escenario en el que usted tiene sus fondos en Arbitrum. Ha elegido usar este dominio específicamente porque es una rollup, lo que significa que (con algunos supuestos razonables) sus fondos están asegurados completamente por los verificadores subyacentes de Ethereum. En otras palabras, sus fondos son lo más cryptoeconómicamente seguros que pueden ser en el ecosistema de blockchain.

Ahora imagine que decide usar un puente para mover sus fondos de manera barata y rápida a Optimism. Optimism también es trustless, por lo que se siente cómodo teniendo sus fondos allí sabiendo que van a compartir el mismo nivel de seguridad (la seguridad de Ethereum) que en Arbitrum.

Sin embargo, el protocolo de puente que usted utiliza tiene su propio conjunto de verificadores externos. Mientras que esto inicialmente puede no parecer un gran problema, sus fondos ya no están asegurados por Ethereum, sino por los verificadores del puente:

1. Si se trata de un puente lock/mint creando wrapped assets, entonces los verificadores del puente pueden coludir unilateralmente para robar todos sus fondos.

2. Si se trata de un puente que utiliza liquidity pools, los verificadores del puente pueden coludir de manera similar para robar todo el capital del pool de los Liquidity Providers.

A pesar de haber esperado por años por L2s seguras y trustless, su situación ahora es la misma que si hubiera usado una trusted sidechain o L1. 😱

La conclusión clave es que los sistemas cryptoeconómicos son solo tan seguros como su eslabón más débil. Cuando utiliza puentes inseguros, ya no importa cuán segura es su cadena o L2. De modo similar a la seguridad de las L1s y L2s, todo se reduce a una pregunta: ¿quién está verificando el sistema?

Una Taxonomía de Protocolos de Interoperabilidad

Podemos clasificar a todos los protocolos de interoperabilidad en tres tipos generales en función de quién los verifica:

Nativamente Verificados

Los protocolos nativamente verificados son aquellos en los que todos los validadores de las cadenas subyacentes se encuentran validando completamente los datos que pasan entre las cadenas. Típicamente esto se hace corriendo un cliente ligero de una cadena en la Virtual Machine de la otra y viceversa.

Ejemplos de éstos incluyen Cosmos IBC y Near RainbowBridge. Las entradas y salidas de rollups también son un tipo especial de puentes nativamente verificados!

Ventajas:

• Es la forma más trustless de interoperabilidad porque los verificadores subyacentes son directamente responsables por el bridging.

• Permite la transferencia de mensajes completamente generalizada entre dominios.

Desventajas:

• Se basa en la confianza subyacente y/o el mecanismo de consenso del dominio para funcionar, por lo que debe ser construido de manera personalizada para cada tipo de dominio.

El ecosistema de Ethereum es altamente heterogéneo: tenemos dominios muy distintos desde ZK/Optimistic rollups, sidechains hasta base chains que corren una amplia variedad de algoritmos de consenso: ETH-PoW (Proof of Work), Nakamoto-PoW, Tendermint-PoS (Proof of Stake), Snowball-PoS, PoA (Proof of Authority), y muchos otros. Cada uno de estos dominios requiere una estrategia única para implementar un sistema de interoperabilidad nativamente verificado.

Externamente Verificado

Los protocolos externamente verificados son aquellos en los que un conjunto de verificadores externos es usado para transmitir datos entre cadenas. Esto es típicamente representado como un sistema MPC (Multi Party Computation), redes de oráculos, o threshold multisig (todos estos son efectivamente la misma cosa).

Ejemplos de éstos incluyen Thorchain, Multichain (Anyswap), Biconomy, Celer, Synapse, PolyNetwork, EvoDeFi, y muchos, muchos otros.

Ventajas:

• Permite la transferencia de mensajes completamente generalizada entre dominios.

• Puede ser extendido fácilmente a cualquier dominio en el ecosistema de Ethereum.

Desventajas:

• Los usuarios y/o los proveedores de liquidez confían sus fondos/datos plenamente en los verificadores externos. Esto significa que el modelo es fundamentalmente menos cryptoeconómicamente seguro que los dominios subyacentes (similar al ejemplo de Arbitrum y Optimism de más arriba).

En algunos casos, los proyectos usan staking adicional o mecanismos de bonding para intentar añadir seguridad para los usuarios. Sin embargo, esto típicamente no tiene mucho sentido económico. Para que un sistema sea trustless, los usuarios deben estar asegurados hasta la máxima cantidad que puede ser robada, y ese seguro debe venir de los verificadores mismos. Esto no solo incrementa significativamente el capital requerido en el sistema, sino que también anula todo el propósito de tener minted assets o liquidity pools en primer lugar.

Localmente Verificado

Los protocolos localmente verificados son aquellos en los que únicamente las partes involucradas en una cierta interacción cross-domain verifican esa interacción. Los protocolos localmente verificados convierten la compleja verificación de n partes en un problema mucho más simple de 2 partes, en las que cada una verifica únicamente a su contraparte. Este modelo funciona mientras ambas partes sean adversarios económicos, es decir, que no haya manera en que las dos partes puedan acordar entre ellas para robar fondos de la cadena en general.

Ejemplos de éstos incluyen Connext, Hop, y otros sistemas simples de atomic swaps.

Ventajas:

• Los sistemas localmente verificados son trustless — su seguridad está garantizada por las cadenas subyacentes dadas algunas consideraciones razonables que son compartidas con las rollups (por ejemplo, que las cadenas no puedan ser censuradas por más de X días).

• También son muy fáciles de extender a otros dominios.

Nota: No todos los sistemas localmente verificados son trustless. Algunos adoptan algunas concesiones de confianza para mejorar la UX (experiencia de usuario) o añadir funcionalidad extra.

Por ejemplo, Hop añade algunos supuestos de confianza a través de su necesidad de un fast arbitrary-messaging-bridge (AMB, Puente de mensajes arbitrarios) en su sistema: el protocolo desbloquea la liquidez de los bonders en 1 día en lugar de esperar los 7 días del período de salida de las rollups. El protocolo también requiere de un puente externamente verificado si no existe ningún AMB para un determinado dominio.

Desventajas:

• Los sistemas localmente verificados no pueden soportar transmisión de datos generalizada entre cadenas.

Esta última frase tiene una sutileza que se reduce a autorización: es posible para un sistema localmente verificado habilitar llamadas de contratos cross-domain pero solo si la función que se está llamando tiene algún tipo de dueño lógico (logical owner). Por ejemplo, es posible llamar de manera trustless a una función de swap de Uniswap entre cadenas porque la función puede ser llamada por cualquiera que tenga tokens que puedan ser intercambiados. Sin embargo, no es posible hacer lock-and-mint (respaldo y minteo) de NFTs de manera trustless entre cadenas. Esto se debe a que el dueño lógico de la función mint en la cadena de destino debería ser el contrato de lock en la cadena de origen, y esto no es posible representarlo en un sistema localmente verificado.

El Trilema de la interoperabilidad

Ahora llegamos a la tesis de este artículo, y el modelo mental que debería impulsar las decisiones de los usuarios y los desarrolladores sobre la selección de puentes.

De modo similar al trilema de la escalabilidad, existe un trilema de la interoperabilidad en el ecosistema de Ethereum. Los protocolos de interoperabilidad solo pueden tener dos de las siguientes tres propiedades:

• Trust-minimization (minimización de la confianza): no añadir ninguna asunción de seguridad económica más allá de la cadena subyacente.

• Generalizabilidad: soportar pasaje de datos arbitrarios cross-chain.

• Extensibilidad: permitir la fácil implementación en muchas cadenas heterogéneas con un trabajo personalizado mínimo.

¿Cómo Encajan Connext y NXTP en Esto?

No hay una manera sencilla para obtener las tres propiedades deseables de la interoperabilidad. Sin embargo, nos hemos dado cuenta de que podemos adoptar el mismo enfoque a resolver el trilema de la interoperabilidad que el enfoque de Ethereum para resolver el trilema de la escalabilidad.

Ethereum L1 optimiza para lograr seguridad y descentralización, a costo de escalabilidad. La razón de esto es que estas propiedades son probablemente las más importantes para la longevidad y la utilidad de una blockchain. Ethereum añade escalabilidad via L2/sharding como una capa por encima de una red troncal segura y descentralizada existente.

En Connext, creemos firmemente que el sistema de interoperabilidad con la mayor longevidad, utilidad, y adoptabilidad en el ecosistema de Ethereum será aquel que es máximamente trustless y extensible. Por esta razón, NXTP es un sistema localmente verificado especialmente diseñado para ser tan seguro como los dominios subyacentes mientras que sigue siendo utilizable en cualquier dominio.

Entonces, ¿qué pasa con la generalizabilidad? De modo similar a la escalabilidad en el ecosistema de Ethereum, podemos agregar generalizabilidad conectando protocolos nativamente verificados encima de NXTP (como una “L2” de nuestra red de interoperabilidad!). De ese modo, los usuarios y los desarrolladores obtienen una interfaz consistente a través de cualquier dominio, y pueden “mejorar” su conexión para ser generalizada en los casos en donde esa funcionalidad está disponible.

Es por esto que decimos que NXTP es el protocolo base de nuestra red de interoperabilidad. La red entera estará hecha de un stack de protocolos que incluirán NXTP, puentes crosschain generalizados específicos para pares de dominios, y protocolos para conectarlos todos en un sistema fluido.

Acerca de Connext

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 barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1300 millones de USD en transacciones han cruzado la red.

Website | Documentation | Twitter | Discord | Github | Blog | Telegram

Muchas gracias a James Prestwich, Eli Krenzke, Dmitriy Berenzon, y en general a la comunidad de investigación de L2 por las conversaciones que han contribuido a las ideas de este post durante los últimos años.😄

¿Por qué NEXT?

En Connext, creemos en el poder que tienen los sistemas descentralizados para poner el valor y la propiedad en manos de las personas en vez de las instituciones. Nuestra misión es hacer a la próxima generación de dapps y protocolos simple, escalable, y segura para el mercado global de usuarios.

Nuestro enfoque en solucionar los obstáculos clave de UX y confianza de un Ethereum escalable nos llevó a construir el primer puente con confianza totalmente minimizada en el ecosistema de Ethereum el año pasado, que hasta la fecha ha completado más de 700.000 transacciones y $1300 millones en volumen .

También es por esto que, a través de nuestra recientemente anunciada actualización de Amarok ( y en asociación con Nomad ), pronto seremos la primera y única red que permite la comunicación generalizada entre cadenas sin introducir contrapartes en las que se debe confiar. Creemos que este avance impulsará una nueva ola de innovación alrededor del desarrollo de trust-minimized crosschain apps (xapp).

Connext está destinado a convertirse en una pieza crítica de infraestructura pública para la web descentralizada, y estamos convencidos que la comunidad es la que debe ser dueña y debe operarla.

Para lograr esto, nos complace presentar NEXT, el token de la Connext Network.

¿Qué es NEXT?

NEXT es un token de utilidad y gobernanza ERC20 que impulsa la utilización justa de la red.

A diferencia de otras soluciones en el espacio de la interoperabilidad, donde la arquitectura de seguridad depende de incentivos económicos (tokens del protocolo), Connext está asegurada directamente por las cadenas subyacentes.

El propósito del token NEXT, entonces, no es proveer seguridad, sino mantener la equidad operativa para los routers tras nuestra actualización de Amarok.

Los routers (nodos de Connext) hacen staking de NEXT para participar en la red, y ganan en proporción al trabajo realizado en la misma. NEXT mantiene a la red en funcionamiento asegurando que todos los routers están sujetos al mismo conjunto de reglas sobre el ordenamiento justo de transacciones, y los NEXT de un router sufren slashing (penalización) si violan las reglas.

Además de su valor como utilidad, NEXT va a ser utilizado para gobernar la tesorería del ecosistema de Connext Network a través de una DAO. Creemos que la comunidad es el mejor árbitro a largo plazo para la asignación de recursos hacia los contribuyentes claves que impulsarán nuestra red.

NOTA: Los snapshots para la distribución de NEXT ya han sido tomadas, y en este momento la única forma en la que los miembros de la comunidad pueden potencialmente ganar más tokens es a través de nuestro Contributor Program que se explica a continuación.

Además, el token ya ha sido minteado, pero no está públicamente disponible aún. ¡Por favor tengan cuidado con estafas y falsas distribuciones de NEXT!

Detalles generales del token:

• Ticker: NEXT

• Standard: ERC20

• Total supply: 1B tokens (1000 millones)

• Token address en Ethereum: 0xd63014F367aFe2eb006FD3dD6C02110A9dCE42dC

• Estado actual: no distribuido

Se publicará más información acerca de la distribución del token y la gobernanza a medida que nos acerquemos al lanzamiento completo del token. Estamos muy entusiasmados por esta nueva fase de Connext como un protocolo y organización completamente descentralizados.

Hora de unirse: Telegram

¿Ahora a dónde? Introduciendo el Contributor Program

Para acelerar la descentralización de Connext, nos complace lanzar nuestro Contributor Program, un programa de incentivos diseñado para alentar a miembros de la comunidad de diferentes orígenes y habilidades a administrar y tomar control de aspectos claves de nuestro ecosistema.

• Fecha de inicio: 20 de abril de 2022.

• Duración: La Fase Uno del programa va a durar hasta el lanzamiento de NEXT, aproximadamente dentro de 1 mes.

El programa consta de 5 Tracks (Community Leadership, Builders, Content & Education, Routers, y Grants), que son operados por Track Operators, líderes experimentados de la comunidad que no forman parte del equipo central.

Los participantes del programa recibirán puntos en función de la calidad de sus contribuciones al ecosistema utilizando criterios de evaluación desarrollados por los Track Operators. Cuando sea lanzado el token NEXT, planeamos enviar una propuesta a la Connext DAO para recompensar retroactivamente a los participantes de manera proporcional a los puntos recibidos.

Esperamos alcanzar una serie de objetivos que son críticos para nuestra misión:

• Escalar la comunidad (activa) y aumentar el reconocimiento del trabajo de Connext.

• Descentralizar iniciativas críticas dentro de la comunidad, como el programa de Community Leadership, Grants, Connext Academy, y la administración del ecosistema de routers.

• Identificar personas con talento en la comunidad y elevarlas a posiciones de liderazgo.

• Construir una comunidad de desarrolladores desde la base que pueda fomentar la adopción del protocolo.

• Impulsar el crecimiento de los routers, y simplificar el proceso de incorporación.

• Educar a miembros de la comunidad (nuevos y existentes) acerca de la visión y tecnología de Connext.

Lamentablemente por razones legales no podemos aceptar participantes de Estados Unidos al Contributor Program en este momento.

Tracks

👫 Community Leaders

Los Community Leaders guían a nuestro ecosistema. Son responsables de administrar comunidades de Connext localizadas en todo el mundo, brindando soporte a usuarios nuevos, educando en sus regiones acerca de la red, administrando espacios sociales para el ecosistema, y protegiendo a la comunidad, defendiendo nuestros valores y políticas.

• Nivel de Habilidades Interpersonales Requerido: Avanzado

• Nivel Técnico Requerido: Bajo

• Presencia Fluida online e IRL: Recomendada

🛠️ Builders

Los Builders son el corazón de la red. Son responsables de desarrollar nuevos casos de uso para el protocolo, integrar Connext en otros ecosistemas, asesorar a nuevos desarrolladores que usan Connext, y evangelizar a Connext en espacios de desarrolladores.

• Nivel Técnico Requerido: Avanzado

• Ethos de Web3: Requerido

• Habilidad de Transformar Bugs en Prestaciones: Apreciada

📚 Content & Education

Los educadores y creadores de contenido ayudan al mundo a aprender sobre Connext. Son responsables de crear contenido de alta calidad en torno a Connext (videos, tweets, medium posts, memes, etc.), y desarrollar recursos educativos técnicos y no técnicos.

• Nivel de Creatividad Requerido: Avanzado

• Conocimiento Técnico: Preferido

• Conocimiento de DeFi/Bridges: Recomendado

🗼Routers

Los routers operan la red. Los miembros de este track corren sus propios routers como parte de nuestra testnet pública de la actualización de Amarok (¡y eventualmente mainnet!), construyen herramientas e interfaces para mejorar la experiencia de operar un router, y en general ayudan a administrar la comunidad de routers.

• Nivel Técnico Requerido: Avanzado

• Pasión por Infraestructura Web3: Requerida

• Deseo Profundo por Automatización: Apreciado

🎁 Grants

Los grantees (receptores de grants) son los innovadores de la red. Mientras que otros tracks encapsulan los mecanismos claves por los que los miembros de la comunidad pueden involucrarse, siempre hay maneras novedosas de apoyar a la red que aún no hemos pensado. Los grantees proponen y reciben fondos para proyectos únicos especiales que se espera harán crecer al ecosistema.

• Nivel Técnico Requerido: Moderado

• Pasión por la Innovación: Requerido

• Mente Abierta: Apreciada

Involucrarse

Para más información acerca de cada track, el código de conducta, y cómo aplicar, visitar: contribución.connext.network

No podemos expresar lo emocionados que estamos por esta nueva fase de Connext, ¡y esperamos que te unas a nosotros en este viaje!

Acerca de Connext

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 barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1300 millones de USD en transacciones han cruzado la red.

Website | Documentation | Twitter | Discord | Github | Blog | Telegram

Gracias a Cintia y Andy

Durante los últimos meses hemos estado recopilando datos e investigando soluciones a los problemas clave que enfrentan los usuarios, desarrolladores, y routers cuando interactúan con Connext.

Hoy nos complace anunciar nuestros planes para la primera actualización de la red de Connext.

La actualización, a la que llamamos Amarok, implica cambios extensos en nuestro protocolo central para mejorar enormemente la experiencia del usuario en la red.

¿Por qué “Amarok”? Hemos elegido nombrar a nuestras actualizaciones de red alfábeticamente como criaturas mitológicas. Amarok es un lobo gigante de la mitología Inuit.🐺

Motivación

El motivo principal de esta actualización es resolver los siguientes problemas clave que existen actualmente para las diferentes partes interesadas en la red.

Problemas para Usuarios Finales

1. Costos de Gas: El flujo actual depende de un proceso de prepare/fulfill de dos fases para completar transacciones entre redes, las cuales no pueden ser agrupadas por lotes fácilmente.

2. Firmar para Reclamar: Completar las transacciones requiere que los usuarios firmen un mensaje para reclamar los fondos. Esto es lo que mantiene a Connext trust-minimized, pero es molesto ya que necesita que los usuarios permanezcan en línea hasta que firmen.

3. Riesgo de Bloqueo de Fondos: Las transacciones de los usuarios tienen una relación 1:1 con un router. Si ese router se apaga o pierde su conexión con la cadena en la mitad de la transacción, los fondos del usuario pueden permanecer atascados hasta que la transacción expire (72 horas).

4. Velocidad: Ya que los usuarios están vinculados a un router determinado para su transacción, cualquier retraso que experimente ese router específico va a ser transmitida al usuario.

5. Fragmentación de Liquidez: La liquidez provista por los routers depende de la ruta, lo que significa que está disponible entre un par de cadenas determinado. A medida que crece el número de cadenas, se vuelve más difícil para los usuarios hacer transacciones grandes.

Problemas para Desarrolladores

1. Dependencias de Subastas Offchain: La mayoría de integraciones en el espacio son solamente de contratos, pero Connext actualmente requiere correr un client-side SDK para encontrar un router para una transacción dada.

2. Firmar para Reclamar: La necesidad de reclamar requiere que los desarrolladores rastreen las transacciones en progreso y pidan al usuario firmar en el momento correcto. Esto añade muchos costos de operación y complejidad comparado con una simple transacción onchain.

3. Falta de Mensajería Generalizada: Connext ya admite llamadas a contratos entre cadenas, pero esto solo puede realizarse de manera segura en algunos casos. Requerir que los desarrolladores aprendan cuándo pueden y cuándo no pueden usar esta función es un gran obstáculo.

Problemas para Routers

1. Rebalanceo: Los routers envían fondos en la cadena de destino y reciben fondos en la de origen. Esto significa que su liquidez se mueve entre cadenas/rollups y puede quedarse atascada, disminuyendo la eficiencia del capital.

2. ROI Poco Claro: El ROI de los routers es notoriamente difícil de calcular con precisión porque el flujo de dos fases significa que los datos necesarios para rastrear los retornos están fragmentados en las cadenas.

3. Necesidad Estricta de Estar en Línea (Liveness): Como mencionamos anteriormente, si los routers no están disponibles durante una transacción, los fondos del usuario pueden bloquearse hasta por 72 horas. Este requisito estricto de permanecer en línea incrementa la dificultad de ser un router.

4. Gas Griefing: Las transacciones pueden ser canceladas como colaboración por los usuarios o por los routers. Sin embargo, cuando esto ocurre, no hay un mecanismo claro para reembolsar los costos de gas iniciales.

Cómo se esperaba resolver estos problemas originalmente?

Anteriormente pensamos que la solución vendría por una combinación de:

• Incentivos — por ejemplo, usando un vAMM para determinar los precios con fin de incentivar el rebalanceo, y slashing (castigo) para maximizar la capacidad de los routers de estar en línea.

• Integración de wallets — con mover el código SDK de Connext a las wallets, se podría haber abstraído a los desarrolladores y usuarios de mantener el esquema “sign-to-claim” (firmar para reclamar).

Nuestro enfoque ha sido asegurar que las transacciones sean tan trust-minimized como sea posible y los obstáctulos mencionados eran concesiones que hacíamos para lograr esa seguridad. Afortunadamente, en los últimos meses hemos investigado sobre una arquitectura mucho mejor que resuelve los problemas mencionados sin perder la minimización de la confianza.

Bienvenidos a Amarok

Interoperabilidad Modular

El avance en nuestro pensamiento proviene de nuestra estrecha asociación con Nomad. Nomad es un puente optimista que nos brinda comunicación completamente expresiva y de confianza minimizada (trust-minimized) en cualquier cadena, pero a cambio de una latencia de 30 minutos.

Nos hemos dado cuenta que, de modo similar a las blockchains mismas, no hay una arquitectura monolítica que nos de todas las propiedades deseables que necesitamos de los puentes, pero podemos acercarnos a la situación ideal con una modularización del stack del protocolo.

Un Nuevo Flujo

El nuevo flujo utiliza Nomad en gran medida (¡y eventualmente otras capas de mensajería localizada!) por su modelo de seguridad. En lugar de requerir firmas, este enfoque simplemente permite que cualquier router aporte capital para la transacción de un usuario, y reclame los fondos que pasan a través de Nomad, similar a los modelos explorados inicialmente por Nova y Hop.

Ya que ningún router es especificado por adelantado, existe el riesgo de que los routers puedan competir entre sí en la mempool para completar una transacción dada. Esto es un resultado subóptimo, ya que perder esta carrera aún cuesta gas a los routers. Para arreglar esto, introducimos un Sequencer (Secuenciador, similar en concepto a un secuenciador de rollup) que es responsable de recolectar ofertas (intentos de transacciones) de los routers y publicarlas en la cadena por lotes.

Nótese que el rol del secuenciador en Connext no afecta a la seguridad central del sistema ni sus fondos de ninguna manera. En cambio, es simplemente un mecanismo diseñado para distribuir de manera justa los ingresos y el trabajo entre routers, lo que puede ser hecho de manera trustless si hay (a) disponibilidad de datos de todas las ofertas de los routers para una transacción del usuario dada, y (b) un proceso determinístico para seleccionar la oferta ganadora. Actualmente estamos investigando enfoques para esto, incluida la posibilidad de hacer que el secuenciador publique los datos a la cadena ó que los routers y el secuenciador logren un Tendermint consensus.

¡Aprende más acerca del nuevo flujo en nuestro post de discusión principal en Github!

Cambios para las Partes Interesadas

Amarok permite un flujo y un conjunto de funciones mucho mejores que creemos que resuelven todos los problemas de las partes interesadas que presentamos anteriormente.

• Flujo Dispara-y-Olvida: En lugar del flujo de dos fases con firmas, todas las transacciones crosschain ahora ocurren en una única transacción en la cadena de envío, simplificando la experiencia de usuario y desarrollador. Además, ya no necesitamos cancelaciones, eliminando los costos de gas griefing para los routers.

• Routing 1-de-N: Cualquier router (o routers) puede completar la transacción de un usuario, quitando la posibilidad de bloqueos de fondos de los usuarios y reduciendo significativamente los requisitos de estar en línea para los routers. Esto también quita por completo la necesidad de correr el código para las subastas offchain por parte de los desarrolladores.

• Liquidez Simplificada: Los routers reciben liquidez en la cadena de destino de una transacción, exactamente donde la proveen. La liquidez ya no es dependiente de la ruta. Esto elimina los dolores de cabeza del rebalanceo y la fragmentación, mejorando enormemente la eficiencia y disponibilidad del capital.

• Transacciones Más Rápidas y Baratas: El nuevo flujo reduce el número de las llamadas onchain de 4→2, haciendo que las transacciones sean no solo mucho más baratas, sino más rápidas.

• Transporte de Mensajes Arbitrarios: Quizás la mejora más interesante de Amarok es la habilidad de los desarrolladores para construir crosschain dapps de modo totalmente expresivo. Esto desbloquea funciones del estilo del desarrollo de Asynchronous JS, incluyendo soporte para callbacks en Solidity. 🤯 ¡Más sobre esto pronto!

¿Qué Sigue?

Línea de Tiempo

Actualmente tenemos una testnet privada completamente funcional corriendo la actualización de Amarok. Estamos trabajando con miembros de la comunidad clave, routers existentes, y algunos socios de prueba de alto perfil para desarrollar y testear la red.

En las próximas semanas planeamos lanzar:

• Un desglose del flujo de integración, los modos de falla, y los supuestos de confianza de Connext tras la actualización.

• Una testnet pública completamente funcional en la que cualquiera puede construir.

• Guías sobre cómo correr un router y participar en la testnet.

• Herramientas/librerías de Solidity para xchain callbacks.

• Un repositorio de ejemplos de crosschain dapps (xapps).

Las auditorías para la actualización están programadas para mayo, con el objetivo de una actualización en mainnet en junio.

Desarrolla con Connext

Hasta ahora, nuestro enfoque como equipo ha estado en descentralizar nuestra red y automatizar el proceso de operar un router. Con la actualización de Amarok, abriremos las puertas a los desarrolladores para que creen un nuevo mundo de xapps.

Que podés construir? Acá una lista de casos de uso que discutimos con nuestros socios:

• Bridging con minteo en la red de destino y respaldo en la de origen

• Bridging con minteo en la red de destino y burning en la de origen.

• Conectar liquidez de DEXes en distintas cadenas en una sola transacción.

• Crosschain vault zaps (proveer liquidez y stakear los LP recibidos en una vault en una sola transacción automatizada y de manera crosschain) y administración de estrategias de vaults.

• Operaciones de protocolo críticas como replicar/sincronizar constantes globales (por ejemplo, PCV) en distintas cadenas.

• Brindar UniV3 TWAPs a todas las cadenas sin introducir oráculos.

• Gobernanza agnóstica de veTokens (posibilidad de votar de manera crosschain).

• Interoperabilidad entre metaversos.

Tenés una idea para una xapp? Hablanos por Discord o aplicá para un grant.

Acerca de Connext

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 barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1300 millones de USD en transacciones han cruzado la red.

Website | Documentation | Twitter | Discord | Github | Blog | Telegram

Thanks toCintia

Hace un par de meses anunciamos nuestra estrecha colaboración con Nomad, un protocolo de comunicación crosschain que utiliza fraud proofs (similar a las Optimistic Rollups) para transmitir datos cross chain.

En este post profundizaremos en cómo funcionan los optimistic bridges, cuáles son sus concesiones, y por qué los amamos.

Resumen: El Trilema de la Interoperabilidad

El Trilema de la Interoperabilidad es un modelo para explicar el espacio de tradeoffs (concesiones) alrededor del bridging, con una taxonomía de los tipos de protocolos de comunicación cross-chain que existen hoy.

Cuando escribimos acerca del trilema el año pasado, clasificamos los puentes en tres tipos, basados en cómo son verificados:

• Localmente verificados (atomic swaps y fast liquidity systems)

• Externamente verificados (multisig, mpc, threshold, PoS, y puentes validadores)

• Nativamente verificados (light client header relays, puentes rollup)

En cada caso el mecanismo de verificación condujo a la concesión de al menos UNA de las tres propiedades deseables:

• Trust-minimization (minimización de la confianza): no añadir ninguna asunción de seguridad económica más allá de la cadena subyacente.

• Generalizabilidad: soportar pasaje de datos arbitrarios cross chain.

• Extensibilidad: permitir la fácil implementación en muchas cadenas heterogéneas con un trabajo personalizado mínimo.

Optimistic Verification (Verificación Optimista)

A diferencia de puentes localmente, externamente, o nativamente verificados, los puentes optimistas exploran una nueva concesión: la latencia.

Así funcionan en rasgos generales:

1. De manera similar a otros puentes, los datos son posteados en una cadena de origen a una función de un contrato por un usuario o DApp.

2. Un agente llamado updater (actualizador) firma una merkle root que contiene los datos de (1) y los postea a la cadena de origen. De manera similar a un rollup sequencer, un updater hace bonding de fondos que están sujetos a slashing (penalización) en caso de fraude.

3. En este punto cualquier sistema repetidor (relayer como Gelato, Keep3r, Biconomy, etc.) puede leer esta root en la cadena de origen y postearla a una o varias cadenas de destino.

4. Postear los datos a la cadena de destino inicia una ventana de fraud proof de 30 minutos (similar al tiempo de retiro de una optimistic rollup). Durante este tiempo, cualquiera que mire la cadena (un watcher) puede probar el fraude en la cadena de origen y desconectar el canal de comunicación al destino. Si esto sucede, el bond del updater es sujeto a slashing (es decir, los fondos que se le otorgaron son confiscados y dados al watcher que realizó la disputa como recompensa).

5. Si ninguna prueba de fraude ocurre en esta ventana de 30 minutos, los datos pasados a la cadena de destino pueden ser considerados finalizados y consumidos por una aplicación. Típicamente esto ocurre haciendo que un proveedor de servicio (processor) entregue una merkle proof de los datos para el puente y luego utilice esos datos para llamar una función de un contrato en la cadena de destino.

Ya que los datos transmitidos son completamente arbitrarios, los puentes optimistas nos permiten construir cualquier tipo de aplicaciones/casos de uso crosschain con confianza mínima. Algunos ejemplos:

• Bridging con minteo en la red de destino y respaldo en la de origen

• Bridging con minteo en la red de destino y burning en la de origen.

• Conectar liquidez de DEXes en distintas cadenas en una sola transacción.

• Crosschain vault zaps (proveer liquidez y stakear los LP recibidos en una vault en una sola transacción automatizada y de manera crosschain) y administración de estrategias de vaults.

• Operaciones de protocolo críticas como replicar/sincronizar constantes globales (por ejemplo, PCV) en distintas cadenas.

• Brindar UniV3 TWAPs a todas las cadenas sin introducir oráculos.

• Gobernanza agnóstica de veTokens (posibilidad de votar de manera crosschain).

• Interoperabilidad entre metaversos.

Modelo de seguridad económica

De manera similar a las optimistic rollups y redes de state channels, los diseños de puentes optimistas dependen de un set de watchers que observen la cadena y reporten fraude. Esto es un modelo de seguridad fundamentalmente diferente de los puentes externamente verificados del mismo modo que las rollups tienen un modelo de seguridad fundamentalmente diferente que las sidechains.

Cryptoeconomía de los Puentes Externamente Verificados

Los puentes externamente verificados (multisig, validadores, PoS, mpc, o threshold) y las sidechains/L1s, utilizan una suposición de mayoría honesta. En otras palabras, m de n participantes en el sistema deben verificar actualizaciones correctamente. En términos criptoeconómicos esto significa:

El costo de atacar a un puente externamente verificado con n verificadores es igual al costo de corromper o hackear m verificadores.

Si los watchers de un sistema optimista (sean rollups, channels, o puentes) son permissionless (y asumimos que la cadena subyacente está activa), entonces el costo económico de atacar el sistema se vuelve ilimitado. Esto es porque no hay manera de asegurar que no haya al menos un único watcher en el mundo operando anónimamente que puede determinar fraude.

Esto tiene una consecuencia interesante:

En un puente optimista, el EV (valor esperado) de un intento de fraude es siempre negativo porque, mientras que las cadenas subyacentes sean seguras, ninguna cantidad de dinero puede garantizar que el ataque será exitoso. Como tal, la cantidad de slashable stake que necesita ser bonded por el updater solo debe ser lo suficientemente alta como para prevenir intentos de fraude (detener griefing).

Es por esto que los sequencers de Optimistic Rollups, por ejemplo, solo necesitan tener un pequeño subconjunto del TVL de la rollup como bond.

Modos de Falla

Quizás la mejora más importante que los puentes optimistas hacen sobre los puentes externamente verificados es intercambiar liveness (actividad) por seguridad. En otras palabras, mientras que la cadena subyacente sea segura, el peor caso teóricamente posible ya no es una pérdida de fondos, sino una parada (detención) del sistema.

Updater DoS

De manera similar a un rollup sequencer, es posible para un updater centralizado detener el sistema maliciosa o accidentalmente si deja de firmar actualizaciones.

Sin embargo, descentralizar el updater de Nomad es una tarea bastante sencilla. Un ejemplo de construcción simple sería tener varios bonded updaters (en lugar de uno solo) y utilizar un enfoque de “turnos” rotativos para firmar actualizaciones, con conmutación por error y slashing si un cierto updater pierde su “turno”.

Fraude de Updater

Cualquier dato que es transmitido entre cadenas en un puente optimista debe ser firmado por el updater, lo que significa que cualquier fraude en el sistema también debe originarse en el updater.

En los puentes optimistas, el fraude siempre es demostrable determinísticamente en la cadena de origen (similar a como el fraude en las optimistic rollups siempre es demostrable en L1). Para hacer esto, el watcher simplemente debe presentar una prueba de una actualización inválida al contrato de la cadena de origen, que resulta en el updater sufriendo slashing. Luego, el watcher presenta un mensaje firmado a la cadena de destino para “desconectar” el canal de comunicación dentro de los 30 minutos y antes de que los datos fraudulentos puedan ser considerados finalizados.

En verdad, no es necesario demostrar fraude en la cadena de destino. Hacerlo en la cadena de origen (home chain) penaliza correctamente al updater, que desincentiva el fraude en primer lugar, y subsecuentemente la desconexión del canal de comunicación mitiga cualquier daño potencial causado. Dicho esto, la habilidad de un watcher para desconectar arbitrariamente el canal de comunicación abre un vector de DoS (Denial of Service), que discutimos abajo.

Watcher DoS

Ya que cualquier watcher puede iniciar la desconexión de un canal de comunicación en un puente optimista, es posible para los watchers hacer griefing/detener permanentemente un canal de comunicación mediante el spam de desconexiones. Nótese que los watchers no ganan nada del sistema por hacer esto (todos los fondos/datos permanecen seguros), y el riesgo de esto es compartimentado por canal de comunicación (es decir, desconectar un canal no tira abajo el sistema entero).

Este tipo de vector de ataque puede ser mitigado en el largo plazo introduciendo el tipo correcto de incentivos para los watchers. Ya que los watchers ganan el slashed bond del updater cuando disputan correctamente, podemos mitigar el watcher griefing introduciendo un impuesto básico para los watchers que inicien una demostración de fraude. Este impuesto debería ser (a) suficientemente alto para desincentivar el spam, así como también (b) suficientemente bajo comparado al updater bond para que los watchers sigan teniendo un fuerte incentivo para iniciar demostraciones de fraude válidas. Otra solución simple sería postear la firma de desconexión generada por el watcher a la cadena de origen y hacerle slashing al watcher si el fraude no fue demostrado.

Por el momento, Nomad maneja este problema mediante un set de watchers autorizados. Esto cambia la seguridad económica del sistema porque ahora hay una cantidad fija/sabida de watchers que podrían ser corrompidos (limitando el costo de ataque). Sin embargo, consideramos que esta es una solución provisoria aceptable porque hay un camino directo y altamente creíble para la minimización de la confianza. Este enfoque también espeja el modo en que otros sistemas fraud proof han sido lanzados:

• Redes de state channels han iniciado históricamente con un set de watchers autorizados para mitigar estos vectores de griefing hasta que el tipo correcto de incentivos puedan ser construidos.

• Las optimistic rollups están actualmente en la misma etapa, en la que las fraud proofs y las disputas no han sido activadas todavía. Mientras que esto significa que las rollups son más trusted actualmente, la comunidad en general entiende que esto se trata solo de “ruedas de entrenamiento” temporarias hasta que las implementaciones maduren.

Fallas de Actividad de Cadena

La suposición central que hemos discutido arriba es que las cadenas subyacentes son capaces de aceptar transacciones de los watchers. Esta asunción es la misma para cualquier sistema basado en fraud proofs, donde la construcción típica tiene alguna proof window en la cual los watchers deben completar una transacción en la cadena.

Nomad ha parametrizado su latencia de 30 minutos basada una en investigación existente sobre el costo de atacar cadenas con finalidad probabilística. Intentaremos deconstruir los estudios/lógica detrás de esta parametrización en un post futuro.

Comparación a Otros Enfoques

Todo sistema distribuido tiene sus concesiones — las comidas gratuitas no existen en el mundo del bridging. La concesión más evidente de los sistemas optimistas es, con mucho, la adición de los 30 minutos de latencia para transferencias, aunque creemos que esto puede ser mitigado usando un diseño modular que pone a Connext como capa por encima (pronto vendrán más noticias sobre esto!).

Puentes M de N

Como mostramos arriba, los puentes optimistas significan un paso adelante gigantesco en términos de seguridad y minimización de la confianza comparado a los puentes externamente verificados (multisig, set de validadores, PoS, mpc, o threshold). El modelo de seguridad 1 de N de los puentes optimistas puede mitigar vectores ataques devastadores relacionados a la colusión o a las llaves privadas comprometidas.

Por ejemplo, el hackeo al Ronin Bridge de $625m USD no habría sido posible si Ronin hubiese utilizado un puente optimista, incluso si todas las llaves hubieran estado comprometidas.

https://twitter.com/_prestwich/status/1508844826359332868?s=20&t=Bcz6K7xDsd94aG4LxQJCSw

Una comparación similar puede hacerse con LayerZero, que utiliza dos conjuntos m de n superpuestos que funcionalmente actúan simplemente como un conjunto m de n más grande (donde el tamaño del conjunto de participantes y los vectores de colusión se vuelven más difíciles de razonar a menos que se conozca la identidad de todos los participantes de ambos conjuntos).

Atomic Swaps y Liquidez Rápida

Los sistemas localmente verificados (como la implementación actual de NXTP de Connext), mientras que son trustless y fáciles de implementar como los puentes optimistas, son incapaces de soportar el pasaje de datos arbitrarios entre cadenas.

En este sentido tienen un rendimiento inferior comparado a los puentes optimistas para cualquier cosa más allá de transferencia de fondos o simples ejecuciones de contratos. Dicho esto, es probable que sigan siendo muy útiles como un mecanismo para mitigar otras concesiones de puentes optimistas (latencia).

Header Relays

Light Client Header Relay Systems (sistemas de transmisión de encabezados de cliente ligero) como IBC funcionan validando el consenso de la cadena B dentro de la Virtual Machine de la cadena A. Los Header Relays nos dan los mejores supuestos de confianza teóricos ya que los conjuntos de validadores de cada cadena subyacente se verifican entre sí — no se introducen partes adicionales (como en los puentes externamente verificados) o supuestos de actividad (como puentes optimistas). Tampoco son sujetos a la concesión de latencia que tienen los puentes optimistas.

Dicho esto, los header relays no están exentos de sus propios desafíos:

• Un cliente ligero personalizado debe ser construido por cada cadena o mecanismo de consenso nuevo que se incorpore.

• Específicamente para Ethereum PoW, el costo de verificar el consenso es prohibitivo debido a altos requisitos de memoria.

• Los header relays pueden no funcionar con optimistic rollups debido al riesgo de un rollback.

Puentes ZK (Zero Knowledge)

Si bien aún no existen puentes ZK en producción, es posible construir puentes basados en pruebas Zero Knowledge que utilizan la misma estrategia que los header relays para validar datos entre cadenas.

De modo similar a los header relays, los puentes ZK tienen estupendas consideraciones de confianza y baja latencia. También son probablemente mucho más baratos que los header relays regulares porque ya no es necesario que la prueba del consenso sea en la cadena. Sin embargo, al hacer esto introducen nuevas concesiones:

• De modo similar a los light client header relays, una estrategia personalizada debe ser desplegada para validar el consenso de cada cadena, y es posible que esto no funcione para optimistic rollups en absoluto. Para los puentes ZK esto es aún más difícil dado que no todas las cadenas implementan los mismos primitivos criptográficos.

• De hecho, no es posible probar todos los modelos de consenso en zero knowledge. En estos casos, algún tipo de artilugio de finalidad es requerido, lo que implica nuevas suposiciones de confianza.

Es probable que existan otros inconvenientes relacionados al costo de prueba y la disponibilidad de datos, aunque estos no han sido investigados en profundidad aún.

El Futuro del Bridging es Optimista

Hasta ahora no hemos tenido mecanismos computacionalmente baratos para transmitir datos arbitrarios entre cadenas que no involucren terceras partes verificadoras en las que se deba confiar. Los puentes optimistas dan un muy alto nivel de seguridad/minimización de la confianza, a la vez que retienen la simplicidad y la facilidad de implementación de los puentes multisig existentes.

Por esta razón estamos increíblemente entusiasmados sobre Nomad y pensamos que representa un gran salto hacia adelante para la comunicación crosschain y crossrollup.

Acerca de Nomad

Nomad es un nuevo diseño para comunicación cross-chain radicalmente más barata sin header verification (verificación de encabezado). Va a formar la capa base de una red de comunicación cross-chain que provee comunicación rápida y barata para todas las cadenas de contratos inteligentes y rollups.

El protocolo de interoperabilidad de Nomad está activo en Ethereum Mainnet, Moonbeam y Milkomeda, y planea implementarse pronto en todas las cadenas principales.

Acerca de Connext

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 barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1300 millones de USD en transacciones han cruzado la red.

Website | Documentation | Twitter | Discord | Github | Blog | Telegram

Muchas gracias a Anna Carroll, James Prestwich, Pranay Mohan, y el resto del equipo de Nomad por las ideas y el feedback que han contribuido a este post!

Este es un gran hito para el lanzamiento de Amarok que nos permite abrir las pruebas a los constructores y nuestra comunidad.

Amarok , el nombre en clave de nuestra próxima actualización de red, permite:

• Puente one-click: transferencias más rápidas, económicas y fluidas cross-chain. Los usuarios siempre recibirán activos nativos (o los activos sintéticos más líquidos y seguros) en su destino.

• Creación de aplicaciones xchain: los desarrolladores ya no están limitados a usuarios, fondos o datos en una sola red. Ahora pueden crear experiencias verdaderamente independientes de la red sin sacrificar la seguridad . Piense en intercambios xchain: intercambiar cualquier activo por cualquier otro, gobernanza xchain, NFTs xchain y mucho más.

El futuro del desarrollo de las dApp

Connext se destruirá en una pieza clave de la infraestructura web3. Ayúdanos a construirlo con el Programa de Contributors.

https://twitter.com/ethereumJoseph/status/1516841318042984450?s=20&t=mil_--iPV40-ZB_rWNcRuw

Amarok es posible gracias al Modular Interoperability Stack (MIS), una pieza de infraestructura de múltiples soluciones para la comunicación cross-chain, componible y expresiva.

El MIS es xChain Bridging & Building

Actualmente, las blockchains individuales luchan por comunicarse entre sí de manera segura, y los activos y las aplicaciones no funcionan a través de distintas cadenas. Es hora de pasar de multichain a xchain.

https://twitter.com/ConnextNetwork/status/1525502697486446592?s=20&t=KBnCPtu4MtTb57TVUfdgtvlGyyymvC5QqykPZP-BuMI

La necesidad de tener una conexión entre ecosistemas que de otro modo estarían aislados (o prácticamente aislados → es decir, lentos) no hará más que aumentar, tanto si se trata de un futuro centrado en Ethereum (comunicación xchain de L2s) como si no ( L1-L1).

Faltaba un protocolo de comunicación entre redes y rollups lo suficientemente flexible y potente como para crear aplicaciones xchain trust-minimized, escalable y generalizable. Hasta ahora.

La actualización de Amarok combina el poder de los protocolos existentes de Connext, Nomad y otra infraestructura. El Modular Interoperability Stack permite movimientos trustless de datos y tokens a través de múltiples redes.

Lleve los tokens a cualquier red, en cualquier momento, con la liquidez necesaria.

El MIS es Componibilidad Segura

El MIS tiene como objetivo superar el trilema de interoperabilidad (como Ethereum+L2 tiene como objetivo superar el trilema de escalabilidad) a través de múltiples capas técnicas que brindan la mejor opción para el enrutamiento cross-chain: lo más seguro y económicamente conveniente.

https://twitter.com/ConnextNetwork/status/1443994919866077198?s=20&t=pwEJPD60fIEi2wZtMsvwVw

El stack es flexible para adaptarse a diferentes necesidades y diferentes partes interesadas. Se puede combinar para crear nuevas aplicaciones xchain-first.

Quién lo va a usar:

• Usuarios → el bridge más seguro en el espacio con un flujo mejorado para que sus transacciones siempre pasen correctamente.

• Builders → API fácil y potente. Cree una aplicación xchain con 2 líneas de código. La API admite integraciones completas basadas en contratos inteligentes. Cuenta con un SDK de TypeScript para la integración directa en aplicaciones web (o NodeJS).

• DAOs (nos encantan los DAOs) → consulta nuestra propuesta para Index Coop

• Otros: entidades centralizadas, instituciones, protocolos,…

El MIS es:

• Rápido: permite al usuario moverse entre redes en cuestión de minutos.

• Escalable : se adapta a cualquier red de contratos inteligentes.

• Trust minimized: no utiliza validadores externos para completar transacciones.

• Ejecutable desde wallets, multisigs (hola Gnosis Safe ❤) y contratos inteligentes.

¿Por qué el stack es tan seguro?

Nomad, la capa de mensajería del MIS, implementa un mecanismo optimista, un enfoque que requiere solo 1 buen actor en el espacio para estar seguro: esta es una mejora masiva en la seguridad en comparación con las soluciones que se basan en una mayoría honesta para validar transacciones.

https://twitter.com/ConnextNetwork/status/1509563224940756992?s=20&t=_pcvKZHUpx_E1RlxPdQwRg

Además de Nomad, Connext proporciona liquidez rápida y segura para que los usuarios y xApps puedan tener acceso inmediato a los fondos en cualquier red, y una API fácil de implementar para ejecutar cualquier operación entre redes.

El MIS es Comunicación Expresiva

Construya xChain dapps que antes eran inimaginables. xChain lending, gobernanza, wrapped NFTs, todo de modo trust minimized.

https://twitter.com/ConnextNetwork/status/1518962057479176192?s=20&t=e-fFKcSth94vr-rYo0HXrg

MIS permite una comunicación xchain completamente expresiva utilizando una única interfaz simple, que incluye patrones de desarrollo de contratos expresivos y callbacks asincrónicas de estilo javascript en diferentes redes.

https://twitter.com/ConnextNetwork/status/1505256394244636674?s=20&t=ZqIVdk0vPnzsyQxHOXHWYA

Un sueño para los desarrolladores, magia para sus usuarios.

Wen? Testnet ahora, mainnet pronto(TM)

A medida que estabilizamos la testnet y completamos las auditorías, estamos ansiosos por pasar a mainnet lo antes posible. ¡Únete a nuestro Discord para early updates!

¿Quieres CONSTRUIR? Aprende más

• Anuncio de Amarok

• ¿Qué son las aplicaciones de cross-chain?

• Kit de inicio para xApps

• Nueva interfaz de usuario del bridge WIP

Acerca de Connext

Connext es una red para comunicación rápida y confiable entre cadenas y rollups. Es el único sistema de interoperabilidad de su especie que hace esto de manera barata y veloz sin introducir nuevos supuestos de confianza. Connext está apuntado a desarrolladores que están buscando construir puentes y otras aplicaciones nativamente cross-chain. Hasta la fecha más de $1500 millones de USD en transacciones han cruzado la red.

Website | Documentation | Twitter | Discord | Github | Blog | Telegram