Connext v2.0 est sur Mainnet

tl;dr : Nous avons expédié la chose ! 🚢

La v2.0 est géniale parce qu’elle : double ce que les gens aiment de la v1, supporte nativement les portefeuilles, allège les points de douleur de la v1, et améliore les hypothèses de confiance.

Les portefeuilles et les dApps peuvent commencer en suivant le démarrage rapide dans nos docs. Un travail en cours (Rinkeby) Dai Card est disponible ici.

Après deux longs mois de tests Rinkeby, d’audits et de correction de bugs, nous avons déployé la v2.0 de Connext ! 🌟

• Le meilleur endroit pour sauter dedans est le guide de démarrage rapide dans nos docs.
• Venez nous parler dans notre discord si vous avez des questions.
• Le code est disponible à : https://github.com/ConnextProject/indra
• Travail en cours Rinkeby v2.0 Dai Card est en direct à : https://rinkeby.indra.connext.network

Qu’en est-il de la carte Dai v2.0 du réseau principal ? Bientôt ! Nous travaillons pour nous assurer qu’il n’y a pas de gotchas de l’interface utilisateur qui pourraient faire perdre des fonds aux utilisateurs.

La v2.0 fonctionne sur Counterfactual. Lorsque vous intégrez la v2.0, vous finirez également par supporter le cadre State Channels – la norme unifiée pour les canaux sur Ethereum.

Comment cela fonctionne-t-il ?

Consultez notre post testnet pour un aperçu de la technologie !

Pourquoi la V2.0 est-elle importante ?

Il y a deux ans, nous avons commencé Connext avec une question simple :

« Comment pouvons-nous amener 1 milliard d’utilisateurs à Ethereum ? »

Cette question nous a conduit à travers de nombreuses itérations de produits à la confluence de la scalabilité, de l’UX et des transferts Ethereum. Nous avons émis l’hypothèse que les utilisateurs finaux veulent une expérience transparente et cohérente dans leurs portefeuilles et leurs applications, qu’ils aient Eth pour le gaz, ou à quel point la blockchain est encombrée, ou même sur quelle sidechain/plasmachain/shard ils se trouvent.

Nous savions que nous avions frappé sur quelque chose d’important lorsque nous avons expédié la v1 Dai Card plus tôt cette année et que nous avons vu des réactions comme celle-ci :

Lors de la construction de la v2.0, nos objectifs étaient simples. Premièrement : doubler ce que les utilisateurs aiment déjà dans Connext. Cela signifiait simplifier davantage les intégrations Connext, réimplémenter un onboarding facile via des liens par défaut, et – plus important encore – continuer à travailler pour rendre nos transferts déjà magiques encore plus rapides.

Deuxièmement : réarchitecturer Connext comme un réseau principalement de portefeuille à portefeuille, auquel les dApps peuvent ensuite s’accrocher pour leurs cas d’utilisation spécifiques. Nous avons constaté que les portefeuilles ont aimé l’expérience utilisateur que la v1 a permis, et nous avons donc repensé le client Connext pour qu’il fonctionne de manière beaucoup plus transparente avec les paradigmes de développement de portefeuilles existants pour la gestion et le stockage des clés.

Troisièmement : repenser notre approche des plus grands points de douleur des utilisateurs. Dans la v1, la partie la plus difficile de Connext était, sans surprise, le processus de dépôt et de retrait du canal onchain. Dans la version 2.0, nous avons non seulement simplifié le processus de dépôt/retrait, mais nous avons également rendu possible pour les portefeuilles d’injecter un fournisseur pour le canal d’un utilisateur dans un dApp, supprimant ainsi la nécessité pour les utilisateurs de déposer dans plus d’un canal au départ. Un autre énorme casse-tête dans la v1 était l’inflexibilité du protocole, ce qui signifie qu’il fallait des semaines ou des mois pour réagir aux commentaires des utilisateurs. Dans la v2.0, nous pouvons au contraire ajouter le support de nouvelles applications ou fonctionnalités en quelques jours.

Quatrièmement : faire des progrès crédibles et significatifs pour devenir un système plus décentralisé et à confiance réduite. Alors que la véritable décentralisation est encore un peu loin, nous avons réussi à passer à un système entièrement non gardienné et à jeter les bases de la mise en œuvre du multihop de style Lightning sans trop de changements de protocole futurs. Nous couvrons cela plus en détail dans les hypothèses de confiance ci-dessous.

v2.0 de Connext est l’aboutissement de tous les commentaires impressionnants que nous avons reçus jusqu’à présent de la communauté, et c’est aussi la première étape vers une couche deux d’Ethereum qui est prête pour une utilisation quotidienne.

Merci à tous de faire partie de notre merveilleux voyage jusqu’à présent !

Hypothèses de confiance

Lorsque nous avons lancé la carte Dai sur la v1 de Connext, nous avons énuméré les principales hypothèses de confiance de notre réseau. Cette fois, nous passerons en revue nos anciennes hypothèses en plus de couvrir les nouvelles introduites dans cette mise à jour.

En cours de vol, certains paiements étaient dépositaires

Dans la v1, les fonds des utilisateurs étaient toujours non dépositaires mais les transferts eux-mêmes, en cours de vol, étaient parfois détenus par le hub. Cela était particulièrement vrai pour les transferts plus conditionnels comme les paiements de liens ou les transferts vers des destinataires hors ligne.

Dans la v2.0, tous les transferts sont entièrement non dépositaires, même lorsqu’ils sont en vol. Le hub n’a pas la possibilité de voler vos fonds. Ceci est possible parce que la v2.0 supporte nativement les mises à jour d’état généralisées dans les canaux, leur donnant beaucoup plus de flexibilité.

Le hub détenait la copie « maître » de l’état et les clients ne sauvegardaient pas l’état par défaut

Dans la v1, si vous étiez hors ligne, le hub était la seule entité qui persistait votre état. C’était génial pour la compatibilité inter-appareils, mais cela signifiait que vous comptiez sur le hub pour restaurer votre état avec précision et pour être sincère lors des litiges. Nous avions initialement l’intention de résoudre ce problème en sauvegardant l’état sur IPFS, mais nous avons depuis décidé d’aller dans une direction différente.

Dans la v2.0, le stockage et la sauvegarde de l’état sont laissés à la charge du portefeuille. L’utilisateur doit avoir une copie locale de l’état pour exécuter un canal, qui agit comme une « copie de travail » persistante de l’état, mais les portefeuilles peuvent et devraient probablement créer d’autres sauvegardes à distance. Les clients ne récupèrent plus l’état du hub par défaut, bien qu’ils puissent optionnellement le faire si l’utilisateur final le souhaite. Nous n’exigeons plus non plus que les conflits de canaux soient résolus par le propriétaire du canal uniquement – cela permet aux fournisseurs de portefeuilles d’agir comme des tours de garde pour leurs utilisateurs.

Les mises à jour se produisent via http et sont censurables

Dans la v1, le hub était un serveur REST et les clients communiquaient les mises à jour via des POST http. C’était une bonne tactique pour garder les choses simples, mais cela signifiait que le hub mandatait un flux maladroit basé sur des requêtes pour mettre à jour les états et pouvait censurer ces mises à jour.

Dans la v2.0, nous sommes passés à NATS – un système de messagerie p2p très évolutif, léger et open source. NATS nous permet d’éloigner le hub du paradigme http-request, ce qui permet d’avoir plusieurs copies indépendantes de l’état. Malheureusement, il nécessite toujours que nous implantions un serveur de messagerie (actuellement hébergé par le hub) pour fonctionner correctement. Cela signifie que bien qu’ils soient maintenant p2p, les messages dans le hub centralisé v2.0 sont toujours censurables comme dans la v1.

La décision d’utiliser spécifiquement NATS est un pas vers la résolution de ce problème, cependant. NATS supporte la messagerie décentralisée (maillée) en regroupant de nombreux serveurs de messagerie ensemble. Cela signifie que nous pouvons expédier des instances de NATS en grappe en tant que partie des nœuds Connext dans notre éventuel réseau décentralisé, afin de décentraliser notre couche de messagerie en tandem.

Les transferts se font à travers le hub et sont censurables

Dans la v1, chaque utilisateur déposait dans des canaux avec le hub et acheminait ensuite les transferts les uns vers les autres à travers le hub (de manière similaire au fonctionnement des relais 0x). Il s’agissait d’une technique d’amorçage pour créer un système fiable et facilement itérable pendant que nous recueillions des données sur les utilisateurs et testions une variété de cas d’utilisation différents. Cela signifiait également, cependant, que notre hub pouvait être censuré, DDoS ou fermé, mettant notre service de paiement hors ligne (bien qu’aucun fonds d’utilisateur ne soit perdu !).

Au lancement, la v2.0 utilise le même paradigme et peut toujours être censurée. Il y a encore du travail à faire avant que nous puissions être un réseau vraiment décentralisé. Cependant, l’ajout de la messagerie p2p et de l’état généralisé est un grand pas dans la bonne direction. Nous pouvons maintenant itérer rapidement sur des protocoles de transfert plus extensibles sans avoir besoin de faire une réécriture complète du système ou de mettre à jour drastiquement les interfaces.

Le client se proxie à travers l’interface du hub pour accéder à Redlock

En décentralisant le stockage de l’état de l’utilisateur, nous avons introduit la complexité liée à la mise à jour concurrente de l’état. Dans les serveurs centralisés, la concurrence est gérée en verrouillant/déverrouillant l’état à chaque opération. Pour notre paradigme distribué, nous avons intégré les verrous distribués de Redis dans le hub. Malheureusement, Redis n’est pas nativement supporté dans les navigateurs et Webdis, l’interface Redis basée sur le navigateur, ne supporte pas Redlock.

Dans l’intérêt d’une expédition efficace, nous avons construit une interface proxy hébergée par le hub pour que le client verrouille/déverrouille son état. À court ou moyen terme, nous prévoyons de réimplémenter ou de modifier Webdis pour utiliser également le verrouillage distribué.

Détails techniques

Les contrats ont été audités de manière indépendante :

• Rapport d’audit de Provide
• Rapport d’audit de Decenter

Contrats du réseau 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

Code du contrat :

• Contrats de protocole de financement contrefactuel
• Contrats d’adjudication contrefactuel

.