v2.0 er fantastisk, fordi det: fordobler det, som folk elsker fra v1, understøtter nativt tegnebøger, afhjælper v1’s smertepunkter og forbedrer tillidsforudsætninger.
Pengesedler og dApps kan komme i gang ved at følge Quick Start i vores docs. En work-in-progress (Rinkeby) Dai Card er tilgængelig her.
Efter to lange måneder med Rinkeby-test, revisioner og fejlrettelse har vi udrullet v2.0 af Connext! 🌟
Det bedste sted at springe ind er Quick Start-guiden i vores docs.
Kom og snak med os i vores discord, hvis du har spørgsmål.
Koden er tilgængelig på: https://github.com/ConnextProject/indra
Work in progress Rinkeby v2.0 Dai Card er live på: https://github.com/ConnextProject/indra
https://rinkeby.indra.connext.network
Hvad med et mainnet v2.0 Dai Card? Snart! Vi arbejder på at sikre, at der ikke er nogen UI gotchas, der kan få brugere til at miste penge.
V2.0 kører på Counterfactual. Når du integrerer v2.0, vil du også i sidste ende understøtte State Channels-rammen – den ensartede standard for kanaler på Ethereum.
Hvordan virker det?
Kig på vores testnet-indlæg for en oversigt over teknologien!
Hvorfor er V2.0 vigtigt?
For to år siden startede vi Connext med et simpelt spørgsmål:
“Hvordan kan vi få 1 milliard brugere til Ethereum?”
Dette spørgsmål førte os gennem en masse produkt-iterationer på sammenløbet af skalerbarhed, UX og Ethereum-overførsler. Vi opstillede den hypotese, at slutbrugerne ønsker en sømløs og ensartet oplevelse i deres tegnebøger og applikationer, uanset om de har Eth for gas, eller hvor overbelastet blockchainen er, eller endda hvilken sidechain/plasmachain/shard de er på.
Vi vidste, at vi havde ramt noget vigtigt, da vi afsendte v1 Dai Card tidligere i år og så reaktioner som denne:
Da vi byggede v2.0, var vores mål enkle. For det første: at fordoble det, som brugerne allerede elsker ved Connext. Det betød at forenkle Connext-integrationer yderligere, genimplementere nem onboarding via links som standard og – vigtigst af alt – fortsætte arbejdet med at gøre vores allerede magiske overførsler endnu hurtigere.
For det andet: Re-arkitere Connext som et primært wallet-to-wallet-netværk, som dApps så kan koble sig på til deres specifikke usecases. Vi fandt ud af, at tegnebøger elskede brugeroplevelsen v1 aktiveret, og derfor har vi redesignet Connext-klienten til at arbejde meget mere problemfrit med eksisterende tegnebogsudviklingsparadigmer for nøglehåndtering og lagring.
Tredje: genoverveje vores tilgang til brugernes største smertepunkter. I v1 var den sværeste del af Connext, ikke overraskende, processen med at indbetale til og hæve fra kanalen onchain. I v2.0 forenklede vi ikke kun indbetaling/udtrækning, men vi gjorde det også meget muligt for tegnebøger at injicere en udbyder for en brugers kanal i en dApp , hvilket fjernede behovet for brugere til at indbetale i mere end én kanal til at begynde med. En anden stor hovedpine i v1 var protokollens ufleksibilitet, hvilket betød, at det tog uger eller måneder at reagere på brugerfeedback. I v2.0 kan vi i stedet tilføje understøttelse af nye applikationer eller funktioner på få dage.
Fjerde: Gør troværdige, meningsfulde fremskridt i retning af at blive et mere tillidsminimeret og decentraliseret system. Selv om ægte decentralisering stadig er et stykke vej væk, er det lykkedes os at gå over til at være fuldt ud noncustodial og lægge grunden til at implementere Lightning-style multihop uden for mange fremtidige protokolændringer. Vi dækker dette mere detaljeret i Tillidsforudsætninger nedenfor.
v2.0 af Connext er kulminationen af al den fantastiske feedback, vi har modtaget indtil videre fra fællesskabet, og er også det første skridt mod et Ethereum lag to, der er klar til dag-til-dag brug.
Tak alle for at være en del af vores vidunderlige rejse indtil videre!
Trustforudsætninger
Da vi lancerede Dai-kortet på v1 af Connext, listede vi de vigtigste trustforudsætninger for vores netværk. Denne gang vil vi gennemgå vores gamle antagelser ud over at dække de nye, der blev indført i denne opdatering.
Mens de var undervejs, var nogle betalinger opbevaret
I v1 var brugernes midler altid ikke opbevaret, men selve overførslerne, mens de var undervejs, blev nogle gange opbevaret af hubben. Dette gjaldt især for mere betingede overførsler som Link-betalinger eller overførsler til offline-modtagere.
I v2.0 er alle overførsler fuldt ud ikke opbevarede, selv når de er under flyvning. Hubben har ingen mulighed for at stjæle dine midler. Dette er muligt, fordi v2.0 nativt understøtter generaliserede tilstandsopdateringer i kanaler, hvilket giver dem meget mere fleksibilitet.
Hub’en havde “master”-kopien af tilstanden, og klienterne tog som standard ikke backup af tilstanden
I v1, hvis du gik offline, var hub’en den eneste enhed, der bevarede din tilstand. Det var godt for kompatibiliteten på tværs af enheder, men det betød, at du var afhængig af, at hubben gendannede din tilstand nøjagtigt og var sandfærdig under tvister. Vi havde oprindeligt til hensigt at løse dette ved at sikkerhedskopiere tilstand på IPFS, men har siden besluttet at gå i en anden retning.
I v2.0 er lagring og sikkerhedskopiering af tilstand overladt til tegnebogen. Brugeren skal have en lokal kopi af tilstanden for at køre en kanal, der fungerer som en vedvarende “arbejdskopi” af tilstanden, men tegnebøger kan og bør sandsynligvis oprette yderligere eksterne sikkerhedskopier. Klienter gendanner ikke længere som standard state fra hubben, selv om de valgfrit kan gøre det, hvis slutbrugeren vælger det. Vi kræver heller ikke længere, at kanalstridigheder kun løses af kanalens ejer – dette gør det muligt for tegnebogsudbydere at fungere som vagttårne for deres brugere.
Opdateringer sker via http og kan censureres
I v1 var hubben en REST-server, og klienter kommunikerede opdateringer via http POST’er. Dette var en god taktik for at holde tingene enkle, men det betød, at hubben pålagde et klodset anmodningsbaseret flow for at opdatere tilstande og kunne censurere disse opdateringer.
I v2.0 er vi overgået til NATS – et meget skalerbart, letvægts, open source, p2p-meddelelsessystem. NATS lader os flytte hubben væk fra http-request-paradigmet, hvilket gør det muligt at have flere uafhængige kopier af tilstanden. Desværre kræver det stadig, at vi implementerer en messaging-server (som i øjeblikket er hostet af hubben) for at fungere korrekt. Det betyder, at selv om de nu er p2p, kan meddelelser i den centraliserede v2.0-hub stadig censureres som i v1.
Den beslutning om at bruge NATS specifikt er dog et skridt i retning af at løse dette problem. NATS understøtter decentraliseret (mesh) messaging ved at klynge mange messaging-servere sammen. Det betyder, at vi kan sende clusterede NATS-instanser som en del af Connext-noderne i vores eventuelle decentrale netværk, for at decentralisere vores messaging-lag i tandem.
Overførsler sker gennem hubben og er censorable
I v1, hver bruger deponerede i kanaler med hubben og dirigerede derefter overførsler til hinanden over hubben (svarende til hvordan 0x relayers fungerer). Dette var en bootstrapping-teknik for at skabe et pålideligt, let iterbart system, mens vi indsamlede brugerdata og testede en række forskellige usecases. Det betød dog også, at vores hub kunne blive censureret, DDoS’d eller lukket ned, hvilket ville sætte vores betalingstjeneste offline (selvom ingen brugermidler ville gå tabt!).
Ved lanceringen bruger v2.0 det samme paradigme og kan stadig blive censureret. Der er stadig arbejde, der skal gøres, før vi kan være et virkelig decentraliseret netværk. Men tilføjelsen af p2p messaging og generaliseret tilstand er et stort skridt i den rigtige retning. Vi kan nu hurtigt iterere på mere udvidelige overførselsprotokoller uden at skulle lave en komplet omskrivning af systemet eller drastisk opdatere grænsefladerne.
Klientproxies gennem hubens grænseflade for at få adgang til Redlock
Ved at decentralisere lagring af brugertilstand introducerede vi kompleksitet i forbindelse med samtidig opdatering af tilstand. I centraliserede servere håndteres samtidighed ved at låse/oplåse tilstand ved hver operation. I vores distribuerede paradigme integrerede vi Redis’ distribuerede låse i hubben. Desværre understøttes Redis ikke naturligt i browsere, og Webdis, den browserbaserede Redis-grænseflade, understøtter ikke Redlock.
Med henblik på effektiv forsendelse byggede vi en proxygrænseflade, der hostes af hubben, så klienten kan låse/opløse sin tilstand. På kort til mellemlang sigt forventer vi at genimplementere eller ændre Webdis til også at bruge distribueret låsning.
Tekniske detaljer
Kontrakter er blevet uafhængigt revideret:
Provide Audit Report
Decenter Audit Report
Mainnet-kontrakter:
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
Kontraktkode:
Kontrakter om kontrafaktisk finansieringsprotokol
Kontrakter om kontrafaktisk tildeling af kontrakter
Kontrakter om kontrafaktisk tildeling af kontrakter
Leave a Reply