Connext v2.0 está en Mainnet

tl;dr: ¡Hemos enviado la cosa! 🚢

La v2.0 es impresionante porque: duplica lo que la gente adora de la v1, soporta de forma nativa los monederos, alivia los puntos de dolor de la v1 y mejora los supuestos de confianza.

Los monederos y las dApps pueden empezar siguiendo el Inicio Rápido en nuestros documentos. Un trabajo en progreso (Rinkeby) Dai Card está disponible aquí.

Después de dos largos meses de pruebas de Rinkeby, auditorías y corrección de errores, ¡hemos desplegado la v2.0 de Connext! 🌟

• El mejor lugar para saltar en la guía de inicio rápido en nuestros docs.
• Venga a hablar con nosotros en nuestro discord si tiene alguna pregunta.
• El código está disponible en: https://github.com/ConnextProject/indra
• Trabajo en curso Rinkeby v2.0 Dai Card está en vivo en: https://rinkeby.indra.connext.network

¿Qué hay de la tarjeta Dai v2.0 de mainnet? Pronto. Estamos trabajando para asegurarnos de que no haya trampas en la interfaz de usuario que puedan hacer que los usuarios pierdan fondos.

La v2.0 funciona con Counterfactual. Cuando integre la v2.0, también será compatible con el marco de Canales de Estado – el estándar unificado para los canales en Ethereum.

¿Cómo funciona?

¡Consulte nuestro post de la red de pruebas para una visión general de la tecnología!

¿Por qué es importante la V2.0?

Hace dos años, empezamos Connext con una simple pregunta:

«¿Cómo podemos traer mil millones de usuarios a Ethereum?»

Esta pregunta nos llevó a través de un montón de iteraciones del producto en la confluencia de escalabilidad, UX y transferencias de Ethereum. Hipotetizamos que los usuarios finales quieren una experiencia fluida y consistente en sus carteras y aplicaciones, independientemente de si tienen Eth para el gas, o de lo congestionada que esté la blockchain, o incluso de la sidechain/plasmachain/shard en la que se encuentren.

Sabíamos que habíamos dado con algo importante cuando enviamos la Dai Card v1 a principios de este año y vimos reacciones como esta:

Cuando construimos la v2.0, nuestros objetivos eran simples. En primer lugar, duplicar lo que los usuarios ya adoran de Connext. Esto significaba simplificar aún más las integraciones de Connext, reimplementar la incorporación fácil a través de enlaces por defecto y, lo que es más importante, seguir trabajando para que nuestras ya mágicas transferencias sean aún más rápidas.

Segundo: rediseñar Connext como una red principalmente de monedero a monedero, a la que las dApps puedan engancharse para sus casos de uso específicos. Descubrimos que a los monederos les encantaba la experiencia de usuario que ofrecía la v1, así que hemos rediseñado el cliente de Connext para que funcione de forma mucho más fluida con los paradigmas de desarrollo de monederos existentes para la gestión y el almacenamiento de claves.

Tercero: repensar nuestro enfoque de los mayores puntos de dolor de los usuarios. En la v1, la parte más difícil de Connext era, como es lógico, el proceso de depósito y retirada del canal onchain. En la v2.0, no sólo simplificamos el depósito/retirada, sino que también hicimos posible que los monederos inyectaran un proveedor para el canal de un usuario en una dApp, eliminando la necesidad de que los usuarios depositaran en más de un canal para empezar. Otro gran dolor de cabeza en la v1 era la inflexibilidad del protocolo, lo que significaba que se tardaba semanas o meses en reaccionar a los comentarios de los usuarios. En la v2.0, en cambio, podemos añadir soporte para nuevas aplicaciones o características en días.

Cuarto: hacer un progreso creíble y significativo para convertirse en un sistema más minimizado y descentralizado. Aunque la verdadera descentralización está todavía un poco lejos, hemos pasado con éxito a ser totalmente no custodiados y hemos sentado las bases para implementar el multisalto al estilo de Lightning sin demasiados cambios de protocolo en el futuro. Cubrimos esto con más detalle en Supuestos de Confianza más abajo.

v2.0 de Connext es la culminación de toda la impresionante retroalimentación que hemos recibido hasta ahora de la comunidad, y es también el primer paso hacia una capa dos de Ethereum que está lista para el uso diario.

¡Gracias a todos por formar parte de nuestro maravilloso viaje hasta ahora!

Supuestos de confianza

Cuando lanzamos la tarjeta Dai en la v1 de Connext, enumeramos los principales supuestos de confianza de nuestra red. Esta vez, repasaremos nuestras antiguas suposiciones además de cubrir las nuevas introducidas en esta actualización.

Mientras estaban en vuelo, algunos pagos eran custodiados

En la v1, los fondos de los usuarios siempre eran no custodiados pero las transferencias mismas, mientras estaban en vuelo, a veces eran retenidas por el centro. Esto era particularmente cierto para las transferencias más condicionales como los pagos de Link o las transferencias a destinatarios fuera de línea.

En la v2.0, todas las transferencias son totalmente no custodiadas, incluso cuando están en vuelo. El centro no tiene la capacidad de robar sus fondos. Esto es posible porque la v2.0 soporta de forma nativa las actualizaciones de estado generalizadas en los canales, dándoles mucha más flexibilidad.

El hub mantenía la copia «maestra» del estado y los clientes no hacían copias de seguridad del estado por defecto

En la v1, si te desconectabas, el hub era la única entidad que persistía tu estado. Esto era genial para la compatibilidad entre dispositivos, pero significaba que dependías del hub para restaurar tu estado con precisión y ser veraz durante las disputas. Originalmente teníamos la intención de resolver esto mediante la copia de seguridad del estado en IPFS, pero desde entonces hemos decidido ir en una dirección diferente.

En la v2.0, el almacenamiento del estado y la copia de seguridad se deja a la cartera. El usuario debe tener una copia local del estado para ejecutar un canal, que actúa como una «copia de trabajo» persistente del estado, pero las carteras pueden y probablemente deberían crear más copias de seguridad remotas. Los clientes ya no recuperan el estado del centro por defecto, aunque pueden hacerlo opcionalmente si el usuario final lo elige. También ya no requerimos que las disputas del canal sean resueltas sólo por el propietario del canal – esto hace posible que los proveedores de carteras actúen como Watchtowers para sus usuarios.

Las actualizaciones ocurren vía http y son censurables

En la v1, el hub era un servidor REST y los clientes comunicaban las actualizaciones vía http POSTs. Esta era una buena táctica para mantener las cosas simples, pero significaba que el hub obligaba a un flujo basado en peticiones para actualizar los estados y podía censurar esas actualizaciones.

En la v2.0, nos hemos trasladado a NATS – un sistema de mensajería p2p altamente escalable, ligero y de código abierto. NATS nos permite alejar el hub del paradigma http-request, haciendo posible tener múltiples copias independientes del estado. Desafortunadamente, todavía requiere que implementemos un servidor de mensajería (actualmente alojado en el hub) para que funcione correctamente. Esto significa que aunque ahora son p2p, los mensajes en el hub centralizado v2.0 siguen siendo censurables como en la v1.

Sin embargo, la decisión de usar NATS específicamente es un paso hacia la solución de este problema. NATS soporta la mensajería descentralizada (malla) mediante la agrupación de muchos servidores de mensajería juntos. Esto significa que podemos enviar instancias de NATS agrupadas como parte de los nodos Connext en nuestra eventual red descentralizada, para descentralizar nuestra capa de mensajería en tándem.

Las transferencias ocurren a través del hub y son censurables

En la v1, cada usuario depositó en canales con el hub y luego enrutó las transferencias entre sí a través del hub (similar a cómo funcionan los repetidores 0x). Esta fue una técnica de arranque para crear un sistema fiable y fácilmente iterable mientras recogíamos datos de los usuarios y probábamos una variedad de casos de uso diferentes. Sin embargo, esto también significaba que nuestro centro podía ser censurado, atacado por DDoS o cerrado, poniendo nuestro servicio de pago fuera de línea (¡aunque no se perderían los fondos de los usuarios!).

En el lanzamiento, la v2.0 utiliza el mismo paradigma y todavía puede ser censurada. Todavía queda trabajo por hacer antes de ser una red verdaderamente descentralizada. Sin embargo, la adición de la mensajería p2p y el estado generalizado es un gran paso en la dirección correcta. Ahora podemos iterar rápidamente en protocolos de transferencia más extensibles sin necesidad de hacer una reescritura completa del sistema o actualizar drásticamente las interfaces.

Los proxies de los clientes a través de la interfaz del hub para acceder a Redlock

Al descentralizar el almacenamiento del estado del usuario, introducimos la complejidad relacionada con la actualización concurrente del estado. En los servidores centralizados, la concurrencia se gestiona bloqueando/desbloqueando el estado en cada operación. Para nuestro paradigma distribuido, integramos los bloqueos distribuidos de Redis en el hub. Desgraciadamente, Redis no está soportado de forma nativa en los navegadores y Webdis, la interfaz de Redis basada en el navegador, no soporta Redlock.

En aras de un envío eficiente, construimos una interfaz proxy alojada en el hub para que el cliente pueda bloquear/desbloquear su estado. A corto o medio plazo, esperamos reimplementar o modificar Webdis para utilizar también el bloqueo distribuido.

Detalles técnicos

Los contratos han sido auditados de forma independiente:

• Proporcionar informe de auditoría
• Informe de auditoría del centro

Contratos de la red principal:

• ChallengeRegistry.sol
• ConditionalTransactionDelegateTarget.sol
• CoinBalanceRefundApp.sol
• MultiAssetMultiPartyCoinTransferInterpreter.sol
• IdentityApp.sol
• MinimumViableMultisig.sol (singleton)
• ProxyFactory.sol
• SingleAssetTwoPartyCoinTransferInterpreter.sol
• TimeLockedPassThrough.sol
• TwoPartyFixedOutcomeInterpreter.sol
• TwoPartyFixedOutcomeFromVirtualAppInterpreter.sol
• SimpleTwoPartySwapApp.sol
• SimpleLinkedTransferApp.sol
• SimpleTransferApp.sol

Código de contrato:

• Contratos de protocolo de financiación contrafactual
• Contratos de adjudicación contrafactual