Connext v2.0 ist im Mainnet

tl;dr: Wir haben das Ding ausgeliefert! 🚢

v2.0 ist großartig, denn es verdoppelt das, was die Leute an v1 lieben, unterstützt nativ Wallets, lindert die Schmerzpunkte von v1 und verbessert die Vertrauensvoraussetzungen.

Wallets und dApps können anfangen, indem sie dem Schnellstart in unseren Dokumenten folgen. Eine Work-in-Progress (Rinkeby) Dai Card ist hier verfügbar.

Nach zwei langen Monaten mit Rinkeby-Tests, Audits und Bugfixing haben wir v2.0 von Connext bereitgestellt! 🌟

• Der beste Ort, um einzusteigen, ist die Schnellstart-Anleitung in unseren Dokumenten.
• Komm zu uns in den Discord, wenn du irgendwelche Fragen hast.
• Der Code ist verfügbar unter: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card is live at: https://rinkeby.indra.connext.network

Wie sieht es mit einer Mainnet v2.0 Dai Card aus? Bald! Wir arbeiten daran, dass es keine Probleme mit der Benutzeroberfläche gibt, die dazu führen könnten, dass Benutzer Geld verlieren.

V2.0 läuft auf Counterfactual. Wenn Sie v2.0 integrieren, werden Sie auch das State Channels-Framework unterstützen – den einheitlichen Standard für Channels auf Ethereum.

Wie funktioniert es?

Schauen Sie sich unseren Testnet-Beitrag für einen Überblick über die Technik an!

Warum ist V2.0 wichtig?

Vor zwei Jahren starteten wir Connext mit einer einfachen Frage:

„Wie können wir 1 Milliarde Nutzer zu Ethereum bringen?“

Diese Frage führte uns durch viele Produktiterationen am Zusammenfluss von Skalierbarkeit, UX und Ethereum-Transfers. Wir stellten die Hypothese auf, dass Endnutzer eine nahtlose und konsistente Erfahrung in ihren Wallets und Anwendungen wünschen, unabhängig davon, ob sie Eth für Gas haben, oder wie überlastet die Blockchain ist, oder sogar auf welcher Sidechain/Plasmachain/Shard sie sich befinden.

Wir wussten, dass wir auf etwas Wichtiges gestoßen waren, als wir Anfang des Jahres die v1 Dai Card auslieferten und Reaktionen wie diese sahen:

Als wir v2.0 entwickelten, waren unsere Ziele einfach. Erstens: Wir wollten das, was die Benutzer bereits an Connext schätzen, weiter ausbauen. Das bedeutete, die Connext-Integrationen weiter zu vereinfachen, ein einfaches Onboarding über Links als Standard zu implementieren und – am wichtigsten – weiter daran zu arbeiten, unsere bereits magischen Transfers noch schneller zu machen.

Zweitens: Connext als primäres Wallet-to-Wallet-Netzwerk neu zu gestalten, in das sich dApps für ihre spezifischen Anwendungsfälle einklinken können. Wir haben festgestellt, dass Wallets die Benutzererfahrung, die v1 ermöglichte, liebten, und deshalb haben wir den Connext-Client so umgestaltet, dass er viel nahtloser mit den bestehenden Paradigmen zur Entwicklung von Wallets für die Schlüsselverwaltung und -speicherung zusammenarbeitet.

Drittens: Überdenken wir unseren Ansatz für die größten Schmerzpunkte der Benutzer. In v1 war der schwierigste Teil von Connext, wenig überraschend, der Prozess der Einzahlung in den und der Abhebung aus dem Kanal onchain. In v2.0 haben wir nicht nur die Ein- und Auszahlungen vereinfacht, sondern auch die Möglichkeit für Wallets geschaffen, einen Provider für den Kanal eines Nutzers in eine dApp zu injizieren, so dass die Nutzer nicht mehr in mehr als einen Kanal einzahlen müssen. Ein weiteres großes Problem in v1 war die Inflexibilität des Protokolls, was bedeutete, dass es Wochen oder Monate dauerte, um auf Nutzerfeedback zu reagieren. In Version 2.0 können wir stattdessen innerhalb von Tagen Unterstützung für neue Anwendungen oder Funktionen hinzufügen.

Viertens: glaubwürdige, sinnvolle Fortschritte auf dem Weg zu einem stärker vertrauensminimierten und dezentralisierten System machen. Während eine echte Dezentralisierung noch in weiter Ferne liegt, sind wir erfolgreich dazu übergegangen, vollständig nicht-vertrauensbasiert zu sein, und haben die Grundlage für die Implementierung von Lightning-ähnlichem Multihop ohne allzu viele zukünftige Protokolländerungen gelegt.

V2.0 von Connext ist der Höhepunkt all des großartigen Feedbacks, das wir bisher von der Community erhalten haben, und ist auch der erste Schritt zu einer Ethereum-Schicht zwei, die für den täglichen Gebrauch bereit ist.

Danke euch allen, dass ihr bisher Teil unserer wunderbaren Reise wart!

Vertrauensannahmen

Als wir die Dai Card auf v1 von Connext eingeführt haben, haben wir die wichtigsten Vertrauensannahmen unseres Netzwerks aufgelistet.

Während des Fluges waren einige Zahlungen verwahrt

In v1 waren die Gelder der Nutzer immer nicht verwahrt, aber die Überweisungen selbst wurden manchmal während des Fluges vom Hub gehalten. Dies galt vor allem für bedingte Überweisungen wie Link-Zahlungen oder Überweisungen an Offline-Empfänger.

In v2.0 sind alle Überweisungen vollständig frei von Verfügungsgewalt, auch während des Transfers. Der Hub hat keine Möglichkeit, Ihr Geld zu stehlen. Dies ist möglich, weil v2.0 von Haus aus allgemeine Statusaktualisierungen in Channels unterstützt, was ihnen viel mehr Flexibilität verleiht.

Der Hub hält die „Master“-Kopie des Status und die Clients haben standardmäßig keinen Status gesichert

In v1 war der Hub die einzige Instanz, die den Status beibehielt, wenn man offline ging. Das war gut für die geräteübergreifende Kompatibilität, bedeutete aber auch, dass man sich darauf verlassen musste, dass der Hub den Status korrekt wiederherstellte und bei Streitigkeiten die Wahrheit sagte. Ursprünglich wollten wir dieses Problem durch die Sicherung des Status auf IPFS lösen, haben uns dann aber entschieden, eine andere Richtung einzuschlagen.

In v2.0 wird die Speicherung und Sicherung des Status der Brieftasche überlassen. Der Benutzer muss über eine lokale Kopie des Zustands verfügen, um einen Channel zu betreiben, der als dauerhafte „Arbeitskopie“ des Zustands fungiert, aber Wallets können und sollten wahrscheinlich weitere Remote-Backups erstellen. Clients stellen den Status nicht mehr standardmäßig vom Hub wieder her, obwohl sie dies optional tun können, wenn der Endbenutzer dies wünscht. Wir verlangen auch nicht mehr, dass Channel-Streitigkeiten nur vom Channel-Besitzer gelöst werden – dies ermöglicht es Wallet-Anbietern, als Watchtower für ihre Nutzer zu fungieren.

Updates erfolgen über http und sind zensierbar

In v1 war der Hub ein REST-Server und Clients kommunizierten Updates über http POSTs. Das war eine gute Taktik, um die Dinge einfach zu halten, aber es bedeutete, dass der Hub einen klobigen, anforderungsbasierten Fluss zur Aktualisierung von Zuständen erforderte und diese Aktualisierungen zensieren konnte.

In v2.0 sind wir zu NATS übergegangen – einem hoch skalierbaren, leichtgewichtigen, quelloffenen P2P-Nachrichtensystem. Mit NATS können wir den Hub vom http-Request-Paradigma wegbewegen, wodurch es möglich wird, mehrere unabhängige Kopien des Status zu haben. Leider erfordert es immer noch, dass wir einen Messaging-Server implementieren (der derzeit vom Hub gehostet wird), damit es richtig funktioniert. Das bedeutet, dass Nachrichten im zentralisierten v2.0-Hub immer noch zensierbar sind wie in v1.

Die Entscheidung, speziell NATS zu verwenden, ist jedoch ein Schritt zur Lösung dieses Problems. NATS unterstützt dezentrales (Mesh) Messaging, indem es viele Messaging-Server zu Clustern zusammenfasst. Das bedeutet, dass wir geclusterte NATS-Instanzen als Teil der Connext-Knoten in unserem späteren dezentralisierten Netzwerk ausliefern können, um unsere Messaging-Schicht im Tandem zu dezentralisieren.

Übertragungen laufen über den Hub und sind zensierbar

In v1 hat jeder Nutzer Kanäle beim Hub hinterlegt und dann Übertragungen untereinander über den Hub geleitet (ähnlich wie 0x-Relayers funktionieren). Dies war eine Bootstrapping-Technik, um ein zuverlässiges, leicht zu wiederholendes System zu schaffen, während wir Nutzerdaten sammelten und eine Vielzahl von verschiedenen Anwendungsfällen testeten. Dies bedeutete jedoch auch, dass unser Hub zensiert, mit DDoS angegriffen oder abgeschaltet werden konnte, wodurch unser Zahlungsdienst offline ging (obwohl keine Nutzergelder verloren gingen!).

Zum Start verwendet v2.0 das gleiche Paradigma und kann immer noch zensiert werden. Es gibt noch einiges zu tun, bevor wir ein wirklich dezentralisiertes Netzwerk sein können. Die Hinzufügung von P2P-Nachrichten und allgemeinem Status ist jedoch ein großer Schritt in die richtige Richtung. Wir können jetzt schnell auf erweiterbare Übertragungsprotokolle umsteigen, ohne das System komplett neu schreiben oder die Schnittstellen drastisch aktualisieren zu müssen.

Client Proxies durch die Hub-Schnittstelle, um auf Redlock zuzugreifen

Durch die Dezentralisierung der Speicherung von Benutzerzuständen haben wir die Komplexität der gleichzeitigen Aktualisierung von Zuständen eingeführt. Bei zentralisierten Servern wird die Gleichzeitigkeit durch Sperren/Entsperren des Zustands bei jeder Operation gehandhabt. Für unser verteiltes Paradigma haben wir die verteilten Sperren von Redis in den Hub integriert. Leider wird Redis in Browsern nicht nativ unterstützt, und Webdis, die browserbasierte Redis-Schnittstelle, unterstützt Redlock nicht.

Im Interesse einer effizienten Auslieferung haben wir eine vom Hub gehostete Proxy-Schnittstelle entwickelt, über die der Client seinen Zustand sperren/entsperren kann. Kurz- bis mittelfristig erwarten wir, Webdis neu zu implementieren oder zu modifizieren, um auch verteiltes Sperren zu verwenden.

Technische Details

Verträge wurden unabhängig geprüft:

• Provide Audit Report
• Decenter Audit Report

Mainnet-Verträge:

• 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

Vertragscode:

• Kontrafaktische Finanzierungsprotokollverträge
• Kontrafaktische Adjudikationsverträge