Connext v2.0 finns på Mainnet

Tl;dr: Vi har skickat ut den! 🚢

v2.0 är fantastisk eftersom den: fördubblar det som folk älskar från v1, har nativt stöd för plånböcker, lindrar v1:s problem och förbättrar förutsättningarna för förtroende.

Plånböcker och dApps kan komma igång genom att följa snabbstarten i vår dokumentation. Ett pågående arbete (Rinkeby) Dai Card finns här.

Efter två långa månader av Rinkeby-testning, revisioner och felrättning har vi distribuerat v2.0 av Connext! 🌟

• Det bästa stället att hoppa in är snabbstartsguiden i vår dokumentation.
• Kom och prata med oss i vår discord om du har några frågor.
• Koden finns på: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card is live at: https://rinkeby.indra.connext.network

Vad sägs om ett mainnet v2.0 Dai Card? Snart! Vi arbetar med att se till att det inte finns några UI gotchas som kan leda till att användare förlorar pengar.

V2.0 körs på Counterfactual. När du integrerar v2.0 kommer du så småningom också att stödja ramverket State Channels – den enhetliga standarden för kanaler på Ethereum.

Hur fungerar det?

Kolla på vårt testnet-inlägg för en översikt över tekniken!

Varför är V2.0 viktigt?

För två år sedan startade vi Connext med en enkel fråga:

”Hur kan vi få 1 miljard användare till Ethereum?”

Denna fråga ledde oss genom många produkt iterationer vid sammanflödet av skalbarhet, UX och Ethereum överföringar. Vi antog att slutanvändarna vill ha en sömlös och konsekvent upplevelse i sina plånböcker och applikationer, oavsett om de har Eth för gas, eller hur överbelastad blockkedjan är, eller till och med vilken sidechain/plasmachain/shard de befinner sig på.

Vi visste att vi hade hittat något viktigt när vi levererade v1 Dai Card tidigare i år och såg reaktioner som denna:

När vi byggde v2.0 var våra mål enkla. För det första: dubbla det som användarna redan älskar med Connext. Detta innebar att förenkla Connext-integrationer ytterligare, återimplementera enkel onboarding via länkar som standard och – viktigast av allt – fortsätta att arbeta med att göra våra redan magiska överföringar ännu snabbare.

För det andra: omarkitera Connext som ett primärt wallet-to-wallet-nätverk, som dApps sedan kan koppla in sig på för sina specifika användningsområden. Vi upptäckte att plånböcker älskade användarupplevelsen som v1 möjliggjorde, och därför har vi gjort om Connext-klienten så att den fungerar mycket smidigare med befintliga utvecklingsparadigm för plånböcker när det gäller nyckelhantering och lagring.

Tredje: ompröva vårt tillvägagångssätt när det gäller användarnas största problemområden. I v1 var det svåraste med Connext, föga förvånande, processen att sätta in och ta ut pengar från kanalen onchain. I v2.0 förenklade vi inte bara insättning/uttag utan gjorde det också mycket möjligt för plånböcker att injicera en leverantör för en användares kanal i en dApp , vilket gör att användarna till att börja med inte behöver sätta in pengar i mer än en kanal. En annan stor huvudvärk i v1 var protokollets oflexibilitet, vilket innebar att det tog veckor eller månader att reagera på användarfeedback. I v2.0 kan vi istället lägga till stöd för nya applikationer eller funktioner på några dagar.

Fjärde: göra trovärdiga, meningsfulla framsteg mot att bli ett mer förtroendeminimerat och decentraliserat system. Även om verklig decentralisering fortfarande är en bit bort, har vi framgångsrikt gått över till att vara helt icke-kustodial och lagt grunden för att implementera Lightning-liknande multihop utan alltför många framtida protokolländringar. Vi täcker detta mer i detalj i Trust Assumptions nedan.

v2.0 av Connext är kulmen på all den fantastiska feedback som vi hittills har fått från samhället, och är också det första steget mot ett Ethereum lager två som är redo för daglig användning.

Tack alla för att ni har varit en del av vår fantastiska resa hittills!

Förtroendeantaganden

När vi lanserade Dai-kortet på v1 av Connext listade vi de viktigaste förtroendeantagandena för vårt nätverk. Den här gången kommer vi att gå igenom våra gamla antaganden förutom att täcka de nya som infördes i den här uppdateringen.

Under flygning var vissa betalningar depåhållande

I v1 var användarnas medel alltid icke depåhållande, men själva överföringarna, under flygning, hölls ibland av hubben. Detta gällde särskilt för mer villkorliga överföringar som Link-betalningar eller överföringar till offline-mottagare.

I v2.0 är alla överföringar helt icke-vårdande, även när de är under flygning. Navet har ingen möjlighet att stjäla dina pengar. Detta är möjligt eftersom v2.0 har nativt stöd för generaliserade statusuppdateringar i kanaler, vilket ger dem mycket större flexibilitet.

Hubben innehade ”huvudkopian” av status och klienterna säkerhetskopierade inte statusen som standard

I v1 var hubben den enda enhet som upprätthöll din status om du blev offline. Detta var bra för kompatibiliteten mellan olika enheter, men innebar att du förlitade dig på att hubben skulle återställa ditt tillstånd korrekt och vara sanningsenlig vid tvister. Vi hade ursprungligen för avsikt att lösa detta genom att säkerhetskopiera tillstånd på IPFS, men har sedan dess beslutat att gå i en annan riktning.

I v2.0 är lagring och säkerhetskopiering av tillstånd upp till plånboken. Användaren måste ha en lokal kopia av tillståndet för att kunna köra en kanal, som fungerar som en beständig ”arbetskopia” av tillståndet, men plånböcker kan och bör förmodligen skapa ytterligare fjärrbackuper. Klienter återställer inte längre status från hubben som standard, även om de kan göra det frivilligt om slutanvändaren väljer det. Vi kräver inte heller längre att kanaltvister endast ska lösas av kanalägaren – detta gör det möjligt för plånboksleverantörer att fungera som Watchtowers för sina användare.

Uppdateringar sker via http och är censurerbara

I v1 var hubben en REST-server och klienterna kommunicerade uppdateringar via http POSTs. Detta var en bra taktik för att hålla saker och ting enkla men innebar att hubben krävde ett klumpigt förfrågningsbaserat flöde för att uppdatera tillstånd och kunde censurera dessa uppdateringar.

I v2.0 har vi flyttat till NATS – ett mycket skalbart, lättviktigt, öppen källkod, p2p-meddelandesystem. Med NATS kan vi flytta hubben bort från http-request-paradigmet, vilket gör det möjligt att ha flera oberoende kopior av tillståndet. Tyvärr kräver det fortfarande att vi implementerar en meddelandeserver (som för närvarande finns i hubben) för att fungera korrekt. Detta innebär att även om de nu är p2p är meddelanden i den centraliserade v2.0-hubben fortfarande censurerbara som i v1.

Beslutet att använda NATS specifikt är dock ett steg mot att lösa detta problem. NATS stöder decentraliserad (mesh) meddelandehantering genom att klustra många meddelandeservrar tillsammans. Detta innebär att vi kan leverera klustrade NATS-instanser som en del av Connext-noderna i vårt eventuella decentraliserade nätverk, för att decentralisera vårt meddelandeskikt samtidigt.

Överföringar sker via hubben och är censurerbara

I v1 satte varje användare in kanaler med hubben och dirigerade sedan överföringar till varandra via hubben (liknande hur 0x relayers fungerar). Detta var en bootstrapping-teknik för att skapa ett tillförlitligt, lätt iterbart system medan vi samlade in användardata och testade en mängd olika användningsfall. Detta innebar dock också att vår hubb kunde censureras, DDoS-attackeras eller stängas ner, vilket gjorde att vår betaltjänst blev offline (även om inga användares pengar skulle gå förlorade!).

Vid lanseringen använder v2.0 samma paradigm och kan fortfarande censureras. Det finns fortfarande arbete som måste göras innan vi kan bli ett verkligt decentraliserat nätverk. Tillägget av p2p-meddelanden och generaliserat tillstånd är dock ett stort steg i rätt riktning. Vi kan nu snabbt iterera på mer utbyggbara överföringsprotokoll utan att behöva göra en fullständig omskrivning av systemet eller drastiskt uppdatera gränssnitten.

Klient proxies genom hubbens gränssnitt för att få tillgång till Redlock

För att decentralisera lagringen av användarnas tillstånd införde vi komplexitet relaterad till samtidiga uppdateringar av tillstånd. I centraliserade servrar hanteras samtidighet genom att låsa/upplåsa tillstånd vid varje operation. För vårt distribuerade paradigm integrerade vi Redis distribuerade lås i hubben. Tyvärr har Redis inte nativt stöd i webbläsare och Webdis, det webbläsarbaserade Redis-gränssnittet, har inte stöd för Redlock.

För att kunna leverera effektivt byggde vi ett proxygränssnitt som hostas av hubben för att klienten ska kunna låsa/låsa upp sitt tillstånd. På kort till medellång sikt räknar vi med att omimplementera eller modifiera Webdis så att det också använder distribuerad låsning.

Tekniska detaljer

Kontrakten har granskats oberoende av varandra:

• Provide Audit Report
• Decenter Audit Report

Mainnetkontrakt:

• 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

Avtalskod:

• Kontrakten om kontrafaktiska finansieringsprotokoll
• Kontrakten om kontrafaktiska beslut