Connext v2.0 on Mainnetissä

tl;dr: Toimitimme sen! 🚢

v2.0 on mahtava, koska se: tuplaa sen, mitä ihmiset rakastavat v1:stä, tukee natiivisti lompakoita, lievittää v1:n kipupisteitä ja parantaa luottamusolettamuksia.

Lompakot ja dAppit pääsevät alkuun seuraamalla pikakäynnistystä asiakirjoissamme. Work-in-progress (Rinkeby) dai-kortti on saatavilla täällä.

Pitkän kahden kuukauden Rinkeby-testauksen, tarkastusten ja bugien korjaamisen jälkeen olemme ottaneet käyttöön Connextin v2.0:n! 🌟

• Paras paikka hypätä sisään on pikakäynnistysopas dokkarissamme.
• Tule juttelemaan kanssamme discordissamme, jos sinulla on kysyttävää.
• Koodi on saatavilla osoitteessa: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card is live at: https://rinkeby.indra.connext.network

Miten olisi mainnet v2.0 Dai Card? Pian! Työskentelemme varmistaaksemme, ettei siinä ole käyttöliittymäongelmia, jotka saattaisivat aiheuttaa käyttäjille varojen menetyksen.

V2.0 toimii Counterfactualilla. Kun integroit v2.0:n, tuet lopulta myös State Channels -kehystä – Ethereumin kanavien yhtenäistettyä standardia.

Miten se toimii?

Katso testnet-postauksestamme yleiskatsaus tekniikkaan!

Miksi V2.0:lla on merkitystä?

Kaksi vuotta sitten aloitimme Connextin yksinkertaisella kysymyksellä:

”Miten voimme tuoda 1 miljardi käyttäjää Ethereumiin?”

Tämä kysymys johti meidät läpi monien tuote-iteraatioiden skaalautuvuuden, UX:n ja Ethereum-siirtojen yhtymäkohdassa. Hypoteesimme oli, että loppukäyttäjät haluavat saumattoman ja johdonmukaisen kokemuksen lompakoissaan ja sovelluksissaan riippumatta siitä, onko heillä Ethereumia kaasua varten tai kuinka ruuhkautunut lohkoketju on tai jopa siitä, missä sivuketjussa/plasmaketjussa/shardissa he ovat.

Tiesimme, että olimme osuneet johonkin tärkeään, kun toimitimme v1 Dai Cardin aiemmin tänä vuonna ja näimme tämänkaltaisia reaktioita:

Kehittäessämme v2.0:aa tavoitteemme olivat yksinkertaiset. Ensinnäkin: tuplata se, mitä käyttäjät jo rakastavat Connextissä. Tämä tarkoitti Connext-integraatioiden yksinkertaistamista entisestään, helpon sisäänkirjautumisen toteuttamista uudelleen linkkien kautta oletusarvoisesti ja – mikä tärkeintä – jatkoimme työskentelyä jo ennestään maagisten siirtojemme nopeuttamiseksi entisestään.

Toiseksi: arkkitehtuurin muuttaminen Connextin ensisijaisesti lompakosta lompakkoon -verkostoksi, johon dApp:t voivat sitten kytkeytyä omiin käyttötarkoituksiinsa. Huomasimme, että lompakot pitivät v1:n mahdollistamasta käyttäjäkokemuksesta, joten suunnittelimme Connext-asiakasohjelman uudelleen niin, että se toimii paljon saumattomammin nykyisten lompakkokehitysparadigmojen kanssa avainten hallinnan ja tallennuksen osalta.

Kolmanneksi: Ajattelemme uudelleen lähestymistapaamme käyttäjien suurimpiin kipupisteisiin. V1:ssä Connextin vaikein osa oli, mikä ei ole yllättävää, tallettaminen kanavaan ja nostaminen kanavasta onchainissa. Vuonna v2.0, emme ainoastaan yksinkertaistanut tallettamista / nostamista, mutta teimme myös paljon mahdollista lompakot injektoida palveluntarjoajan käyttäjän kanavan dApp , poistaa tarpeen käyttäjien tallettaa useampaan kuin yhteen kanavaan aluksi. Toinen suuri päänsärky v1:ssä oli protokollan joustamattomuus, joten käyttäjien palautteeseen reagoiminen kesti viikkoja tai kuukausia. Sen sijaan v2.0:ssa voimme lisätä tuen uusille sovelluksille tai ominaisuuksille muutamassa päivässä.

Neljänneksi: edistymme uskottavasti ja mielekkäästi kohti entistä luottamusta vähentävää ja hajautetumpaa järjestelmää. Vaikka todellinen hajauttaminen on vielä kaukana, siirryimme menestyksekkäästi siihen, että järjestelmä on täysin ei-luottamuksellinen, ja loimme pohjan Lightning-tyylisen multihopin toteuttamiselle ilman liian monia tulevia protokollamuutoksia. Käsittelemme tätä yksityiskohtaisemmin alla olevassa kohdassa Trust Assumptions.

Connextin versio 2.0 on huipentuma kaikesta mahtavasta palautteesta, jota olemme tähän mennessä saaneet yhteisöltä, ja se on myös ensimmäinen askel kohti Ethereumin kakkoskerrosta, joka on valmis päivittäiseen käyttöön.

Kiitos kaikille siitä, että olette olleet mukana tähänastisella upealla matkallamme!

Luottamusoletukset

Kun lanseerasimme Dai-kortin Connextin v1:ssä, listasimme verkostomme tärkeimmät luottamusoletukset. Tällä kertaa käymme läpi vanhat olettamuksemme sen lisäksi, että käsittelemme tässä päivityksessä käyttöön otettuja uusia olettamuksia.

Lennon aikana jotkin maksut olivat säilytettäviä

V1:ssä käyttäjien varat olivat aina ei-säilytettäviä, mutta itse siirrot olivat lennon aikana joskus keskuksen hallussa. Tämä koski erityisesti ehdollisempia siirtoja, kuten Link-maksuja tai siirtoja offline-vastaanottajille.

V2.0:ssa kaikki siirrot ovat täysin ei-säilytettävissä, myös lennon aikana. Keskittymällä ei ole kykyä varastaa varojasi. Tämä on mahdollista, koska v2.0 tukee natiivisti yleistettyjä tilapäivityksiä kanavissa, mikä antaa niille paljon enemmän joustavuutta.

Keskus piti hallussaan tilan ”pääkopiota” ja asiakkaat eivät oletusarvoisesti varmuuskopioineet tilaa

V1:ssä, jos menit offline-tilaan, keskus oli ainoa taho, joka säilytti tilasi. Tämä oli hienoa laitteiden välisen yhteensopivuuden kannalta, mutta tarkoitti sitä, että olit riippuvainen siitä, että keskittymä palautti tilasi tarkasti ja oli totuudenmukainen riitojen aikana. Alun perin tarkoituksenamme oli ratkaista tämä varmuuskopioimalla tila IPFS:ään, mutta olemme sittemmin päättäneet mennä toiseen suuntaan.

V2.0:ssa tilan tallentaminen ja varmuuskopiointi on jätetty lompakon tehtäväksi. Käyttäjällä on oltava paikallinen kopio tilasta, jotta hän voi käyttää kanavaa, joka toimii pysyvänä ”työkopiona” tilasta, mutta lompakot voivat ja luultavasti niiden pitäisikin luoda lisää etävarmistuksia. Asiakkaat eivät enää oletusarvoisesti palauta tilaa keskuksesta, vaikka ne voivat tehdä niin valinnaisesti, jos loppukäyttäjä niin haluaa. Emme myöskään enää vaadi, että kanavan riitoja ratkaisee vain kanavan omistaja – tämä mahdollistaa lompakkopalvelujen tarjoajien toimimisen käyttäjiensä vartiotornina.

Päivitykset tapahtuvat http:n kautta ja ovat sensuroitavissa

V1:ssä hubi oli REST-palvelin, ja asiakkaat viestivät päivityksistä http-POSTeilla. Tämä oli hyvä taktiikka pitää asiat yksinkertaisina, mutta tarkoitti sitä, että hubi määräsi kömpelön pyyntöpohjaisen virtauksen tilojen päivittämiseen ja saattoi sensuroida nämä päivitykset.

V2.0:ssa siirryimme käyttämään NATS:ää – erittäin skaalautuvaa, kevyttä, avoimen lähdekoodin p2p-viestijärjestelmää. NATS:n avulla voimme siirtää keskuksen pois http-pyyntöparadigmasta, mikä mahdollistaa useiden itsenäisten tilakopioiden käytön. Valitettavasti se edellyttää edelleen, että toteutamme viestipalvelimen (joka on tällä hetkellä keskuksen isännöimä), jotta se toimisi kunnolla. Tämä tarkoittaa sitä, että vaikka viestit ovat nyt p2p-viestejä, keskitetyn v2.0-keskittymän viestit ovat edelleen sensuroitavissa kuten v1:ssä.

Päätös käyttää nimenomaan NATS:ää on kuitenkin askel kohti tämän ongelman ratkaisua. NATS tukee hajautettua (mesh) viestinvälitystä klusteroimalla monia viestipalvelimia yhteen. Tämä tarkoittaa sitä, että voimme toimittaa klusteroituja NATS-instansseja osana Connext-solmuja mahdollisessa hajautetussa verkossamme hajauttaaksemme samalla viestikerrostamme.

Siirrot tapahtuvat keskittimen kautta ja ovat sensuroitavissa

V1:ssä jokainen käyttäjä talletti kanaviin keskittimen kanssa ja reititti sitten siirrot toisilleen keskittimen kautta (samaan tapaan kuin 0x-tiedonsiirtäjät toimivat). Tämä oli bootstrapping-tekniikka luotettavan, helposti iteroitavan järjestelmän luomiseksi samalla, kun keräsimme käyttäjätietoja ja testasimme erilaisia käyttötapauksia. Tämä tarkoitti kuitenkin myös sitä, että hubiamme voitiin sensuroida, sitä voitiin hyökätä DDoS-iskuilla tai se voitiin sulkea, jolloin maksupalvelumme ei toiminut (vaikka käyttäjien varoja ei menetettäisi!).

Käynnistettäessä v2.0 käyttää samaa paradigmaa, ja sitä voidaan edelleen sensuroida. Vielä on tehtävää, ennen kuin voimme olla todella hajautettu verkko. Kuitenkin p2p-viestien ja yleistetyn tilan lisääminen on valtava askel oikeaan suuntaan. Voimme nyt nopeasti iteroida laajennettavampia siirtoprotokollia tarvitsematta kirjoittaa järjestelmää kokonaan uusiksi tai päivittää rajapintoja rajusti.

Asiakas käyttää hubin rajapinnan kautta välityspalvelimia päästäkseen käsiksi Redlockiin

Hajauttamalla käyttäjien tilan tallentamisen hajautetusti lisäsimme monimutkaisuutta, joka liittyy tilan samanaikaiseen päivittämiseen. Keskitetyissä palvelimissa samanaikaisuus hoidetaan lukitsemalla/avoimistamalla tila jokaisen operaation yhteydessä. Hajautettua paradigmaamme varten integroimme Redisin hajautetut lukitukset keskukseen. Valitettavasti Redis ei ole natiivisti tuettu selaimissa, eikä Webdis, selainpohjainen Redis-käyttöliittymä, tue Redlockia.

Tehokkaan toimituksen vuoksi rakensimme keskuksen isännöimän välityspalvelurajapinnan, jonka avulla asiakas voi lukita ja purkaa tilansa. Lyhyellä tai keskipitkällä aikavälillä odotamme, että toteutamme uudelleen tai muokkaamme Webdisin käyttämään myös hajautettua lukitusta.

Tekniset yksityiskohdat

Sopimukset on tarkastettu riippumattomasti:

• Tarkastusraportti
• Keskustarkastusraportti

Pääverkkosopimukset:

• 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

Sopimuskoodit:

• Vastakkaiset rahoituspöytäkirjasopimukset
• Vastakkaiset tuomiolausekesopimukset