Connext v2.0 is op Mainnet

tl;dr: We hebben het ding verscheept! 🚢

v2.0 is geweldig omdat het: verdubbelt wat mensen leuk vinden aan v1, wallets ondersteunt, de pijnpunten van v1 verlicht, en de aannames over vertrouwen verbetert.

Wallets en dApps kunnen aan de slag door de Quick Start in onze docs te volgen. Een work-in-progress (Rinkeby) Dai Card is hier beschikbaar.

Na een lange twee maanden van Rinkeby testen, audits, en bugfixing, hebben we v2.0 van Connext uitgerold! 🌟

• De beste plaats om in te springen is de Quick Start guide in onze docs.
• Kom met ons praten in onze discord als je vragen hebt.
• Code is beschikbaar op: https://github.com/ConnextProject/indra
• Werk in uitvoering Rinkeby v2.0 Dai Card is live op: https://rinkeby.indra.connext.network

Wat dacht u van een mainnet v2.0 Dai Card? Binnenkort! We werken eraan om ervoor te zorgen dat er geen UI gotchas zijn waardoor gebruikers geld zouden kunnen verliezen.

V2.0 draait op Counterfactual. Wanneer je v2.0 integreert, zul je uiteindelijk ook het State Channels framework ondersteunen – de uniforme standaard voor kanalen op Ethereum.

Hoe werkt het?

Kijk onze testnet post voor een overzicht van de tech!

Waarom is V2.0 van belang?

Twee jaar geleden begonnen we Connext met een eenvoudige vraag:

“Hoe kunnen we 1 miljard gebruikers naar Ethereum brengen?”

Deze vraag leidde ons door een heleboel product iteraties op het raakvlak van schaalbaarheid, UX en Ethereum transfers. We stelden als hypothese dat eindgebruikers een naadloze en consistente ervaring willen in hun portemonnees en toepassingen, ongeacht of ze Eth voor gas hebben, of hoe overbelast de blockchain is, of zelfs op welke sidechain/plasmachain/shard ze zich bevinden.

We wisten dat we iets belangrijks hadden gevonden toen we eerder dit jaar de v1 Dai Card verscheepten en reacties als deze zagen:

Bij het bouwen van v2.0 waren onze doelen simpel. Ten eerste: nog beter inspelen op wat gebruikers al zo waarderen aan Connext. Dit betekende dat Connext-integraties verder moesten worden vereenvoudigd, dat eenvoudige onboarding via links als standaard moest worden geïmplementeerd en – het belangrijkste – dat we moesten blijven werken aan het nog sneller maken van onze toch al magische overschrijvingen.

Tweede: Connext herontwerpen als een primair portemonnee-naar-wallet-netwerk, waar dApps vervolgens op kunnen inhaken voor hun specifieke toepassingen. We hebben gemerkt dat wallets dol zijn op de gebruikerservaring die v1 mogelijk maakt, en daarom hebben we de Connext-client opnieuw ontworpen om veel naadlozer samen te werken met bestaande wallet-ontwikkelingsparadigma’s voor sleutelbeheer en opslag.

Derde: heroverweeg onze aanpak van de grootste pijnpunten van gebruikers. In v1, het moeilijkste deel over Connext was, unsurprisingly, het proces van storten in en opnemen uit het kanaal onchain. In v2.0 hebben we niet alleen het storten/opnemen vereenvoudigd, maar we hebben het ook veel mogelijk gemaakt voor wallets om een provider voor het kanaal van een gebruiker in een dApp te injecteren, waardoor de noodzaak voor gebruikers om te storten in meer dan een kanaal om mee te beginnen werd weggenomen. Een andere grote kopzorg in v1 was de inflexibiliteit van het protocol, wat betekende dat het weken of maanden duurde om te reageren op feedback van gebruikers. In v2.0, kunnen we in plaats daarvan ondersteuning voor nieuwe toepassingen of functies in dagen toevoegen.

Vier: maak geloofwaardige, zinvolle vooruitgang in de richting van een meer op vertrouwen geminimaliseerd en gedecentraliseerd systeem. Hoewel echte decentralisatie nog ver weg is, zijn we er in geslaagd om volledig non-custodial te worden en hebben we de basis gelegd voor de implementatie van Lightning-stijl multihop zonder al te veel toekomstige protocol veranderingen. We behandelen dit in meer detail in Trust Assumptions hieronder.

v2.0 van Connext is het hoogtepunt van alle geweldige feedback die we tot nu toe hebben ontvangen van de gemeenschap, en is ook de eerste stap naar een Ethereum laag twee die klaar is voor dagelijks gebruik.

Dank u allen voor het deel uitmaken van onze prachtige reis tot nu toe!

Trouwensveronderstellingen

Toen we de Dai Card op v1 van Connext lanceerden, hebben we de belangrijkste vertrouwensveronderstellingen van ons netwerk opgesomd. Deze keer zullen we onze oude aannames herzien, naast de nieuwe die in deze update zijn geïntroduceerd.

Tijdens de vlucht waren sommige betalingen custodial

In v1 waren gebruikersfondsen altijd noncustodial, maar overschrijvingen zelf, tijdens de vlucht, werden soms vastgehouden door de hub. Dit gold met name voor meer voorwaardelijke overschrijvingen, zoals Link-betalingen of overschrijvingen naar offline ontvangers.

In v2.0, zijn alle overschrijvingen volledig noncustodial, zelfs als ze in de lucht zijn. De hub heeft niet de mogelijkheid om uw fondsen te stelen. Dit is mogelijk omdat v2.0 van nature gegeneraliseerde statusupdates in kanalen ondersteunt, waardoor ze veel meer flexibiliteit hebben.

De hub hield de “master” kopie van de status en clients maakten standaard geen backup van de status

In v1, als je offline ging, was de hub de enige entiteit die je status bewaarde. Dit was geweldig voor cross-device compatibiliteit, maar betekende dat je afhankelijk was van de hub om je status nauwkeurig te herstellen en om waarheidsgetrouw te zijn tijdens geschillen. We waren oorspronkelijk van plan om dit op te lossen door een backup te maken op IPFS, maar hebben sindsdien besloten om een andere richting in te slaan.

In v2.0, wordt de opslag en backup van de status overgelaten aan de portemonnee. De gebruiker moet een lokale kopie van de staat hebben om een kanaal te kunnen gebruiken, dat fungeert als een blijvende “werkkopie” van de staat, maar portemonnees kunnen en moeten waarschijnlijk verdere remote back-ups maken. Clients halen de toestand standaard niet meer terug van de hub, hoewel ze dat optioneel wel kunnen doen als de eindgebruiker daarvoor kiest. We vereisen ook niet langer dat kanaalgeschillen alleen door de kanaaleigenaar worden opgelost – dit maakt het mogelijk voor wallet-aanbieders om als Watchtowers voor hun gebruikers te fungeren.

Updates gebeuren via http en zijn censureerbaar

In v1 was de hub een REST-server en klanten communiceerden updates via http POSTs. Dit was een goede tactiek om de dingen eenvoudig te houden, maar betekende dat de hub een onhandige verzoek-gebaseerde stroom oplegde om toestanden bij te werken en die updates kon censureren.

In v2.0 zijn we overgestapt op NATS – een zeer schaalbaar, lichtgewicht, open source, p2p messaging systeem. NATS laat ons de hub weg bewegen van het http-request paradigma, en maakt het mogelijk om meerdere onafhankelijke kopieën van de status te hebben. Helaas vereist het nog steeds dat we een berichtenserver implementeren (momenteel gehost door de hub) om goed te werken. Dit betekent dat, hoewel ze nu p2p zijn, berichten in de gecentraliseerde v2.0 hub nog steeds censureerbaar zijn zoals in v1.

De beslissing om NATS specifiek te gebruiken is een stap in de richting van het oplossen van dit probleem, hoewel. NATS ondersteunt gedecentraliseerde (mesh) messaging door vele messaging servers te clusteren. Dit betekent dat we geclusterde NATS instanties kunnen verschepen als onderdeel van de Connext nodes in ons uiteindelijke gedecentraliseerde netwerk, om onze messaging laag in tandem te decentraliseren.

Overdrachten gebeuren via de hub en zijn censureerbaar

In v1, stortte iedere gebruiker zich in kanalen met de hub en stuurde dan overdrachten naar elkaar over de hub (vergelijkbaar met hoe 0x relayers werken). Dit was een bootstrapping techniek om een betrouwbaar, gemakkelijk iterable systeem te maken terwijl we gebruikersgegevens verzamelden en een verscheidenheid van verschillende usecases testten. Dit betekende echter ook dat onze hub gecensureerd, DDoS’d of afgesloten kon worden, waardoor onze betalingsdienst offline zou gaan (hoewel er geen gebruikersgeld verloren zou gaan!).

Bij de lancering gebruikt v2.0 hetzelfde paradigma en kan nog steeds gecensureerd worden. Er is nog werk te doen voordat we een echt gedecentraliseerd netwerk kunnen zijn. Echter, de toevoeging van p2p messaging en gegeneraliseerde staat is een grote stap in de goede richting. We kunnen nu snel itereren op meer uitbreidbare overdrachtsprotocollen zonder het systeem volledig te moeten herschrijven of interfaces drastisch te moeten updaten.

Client proxies via de interface van de hub om toegang te krijgen tot Redlock

Door de opslag van gebruikersstatus te decentraliseren, hebben we complexiteit geïntroduceerd met betrekking tot het gelijktijdig updaten van status. In gecentraliseerde servers, wordt concurrency afgehandeld door het vergrendelen/ontgrendelen van de status bij elke operatie. Voor ons gedistribueerde paradigma hebben we Redis’ gedistribueerde vergrendelingen in de hub geïntegreerd. Helaas wordt Redis niet ondersteund door browsers en Webdis, de browser-gebaseerde Redis interface, ondersteunt Redlock niet.

In het belang van efficiënte verzending, hebben we een proxy interface gebouwd, gehost door de hub, voor de client om zijn status te locken/unlocken. Op korte tot middellange termijn verwachten we Webdis te herimplementeren of aan te passen om ook gedistribueerde vergrendeling te gebruiken.

Technische details

Contracten zijn onafhankelijk geaudit:

• Provide Audit Report
• Decenter Audit Report

Mainnet contracten:

• ChallengeRegistry.sol
• ConditionalTransactionDelegateTarget.sol
• CoinBalanceRefundApp.sol
• MultiAssetMultiPartyCoinTransferInterpretter.sol
• IdentityApp.sol
• MinimumViableMultisig.sol (singleton)
• ProxyFactory.sol
• SingleAssetTwoPartyCoinTransferInterpretter.sol
• TimeLockedPassThrough.sol
• TwoPartyFixedOutcomeInterpretter.sol
• TwoPartyFixedOutcomeFromVirtualAppInterpretter.sol
• SimpleTwoPartySwapApp.sol
• SimpleLinkedTransferApp.sol
• SimpleTransferApp.sol

Contractcode:

• Counterfactual Funding Protocol contracten
• Counterfactual Adjudication contracten