Connext v2.0 a Mainnet-en

tl;dr: Elszállítottuk a dolgot! 🚢

A v2.0 fantasztikus, mert: megduplázza azt, amit az emberek szeretnek a v1-ből, natívan támogatja a pénztárcákat, enyhíti a v1 fájdalmas pontjait, és javítja a bizalmi feltételezéseket.

A pénztárcák és dAppok a dokumentációnkban található gyorsindítással kezdhetik el. Egy folyamatban lévő (Rinkeby) dai kártya itt érhető el.

A Rinkeby teszteléssel, ellenőrzésekkel és hibajavítással töltött hosszú két hónap után telepítettük a Connext v2.0-ás verzióját! 🌟

• A legjobb hely, ahol belevághatsz, a gyorsindítási útmutató a dokumentációnkban.
• Jöjj, beszélj velünk a discordon, ha bármilyen kérdésed van.
• A kód elérhető a következő címen: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card is live at: https://rinkeby.indra.connext.network

Mi a helyzet a mainnet v2.0 Dai kártyával? Hamarosan! Azon dolgozunk, hogy ne legyenek olyan UI gubancok, amelyek miatt a felhasználók elveszíthetik a pénzüket.

A v2.0 Counterfactualon fut. Ha integrálod a v2.0-t, akkor végül támogatni fogod a State Channels keretrendszert is – a csatornák egységes szabványát az Ethereumon.

Hogyan működik?

Nézd meg a tesztnet posztunkat a technológia áttekintéséért!

Miért fontos a V2.0?

Két évvel ezelőtt egy egyszerű kérdéssel indítottuk el a Connextet:

“Hogyan tudunk 1 milliárd felhasználót az Ethereumhoz juttatni?”

Ez a kérdés rengeteg termékiteráción keresztül vezetett minket a skálázhatóság, az UX és az Ethereum transzferek találkozásánál. Feltételeztük, hogy a végfelhasználók zökkenőmentes és konzisztens élményt szeretnének a pénztárcájukban és az alkalmazásaikban, függetlenül attól, hogy van-e Ethereum gázsijuk, vagy mennyire zsúfolt a blokklánc, vagy akár attól, hogy milyen oldalláncon/plasmachain/shardon vannak.

Azt tudtuk, hogy valami fontosat találtunk, amikor az év elején kiszállítottuk a v1 Dai Cardot, és ilyen reakciókat láttunk:

A v2.0 megalkotásakor a céljaink egyszerűek voltak. Először is: megduplázni azt, amit a felhasználók már most is szeretnek a Connextben. Ez azt jelentette, hogy tovább egyszerűsítettük a Connext integrációkat, alapértelmezettként újra megvalósítottuk a linkeken keresztül történő egyszerű beszállást, és – ami a legfontosabb – tovább dolgoztunk azon, hogy a már most is varázslatos átutalások még gyorsabbak legyenek.

Második: a Connextet elsősorban pénztárca-tárca hálózattá architektúráltuk át, amelybe a dAppok a saját speciális felhasználási eseteikhez kapcsolódhatnak. Úgy találtuk, hogy a tárcák imádták a v1 által lehetővé tett felhasználói élményt, ezért újraterveztük a Connext klienst, hogy sokkal zökkenőmentesebben működjön együtt a meglévő tárcafejlesztési paradigmákkal a kulcskezelés és tárolás terén.

Harmadszor: újragondoltuk a felhasználók legnagyobb fájdalmas pontjainak megközelítését. A v1-ben a Connext legnehezebb része – nem meglepő módon – a csatornába való befizetés és a csatornából való kivonás folyamata volt onchain. A v2.0-ban nem csak egyszerűsítettük a befizetést/kivételt, hanem lehetővé tettük a pénztárcák számára, hogy a felhasználó csatornájának szolgáltatóját injektálják egy dApp-ba , megszüntetve annak szükségességét, hogy a felhasználóknak kezdetben egynél több csatornába kelljen befizetniük. A másik nagy fejfájás a v1-ben a protokoll rugalmatlansága volt, ami azt jelentette, hogy hetekig vagy hónapokig tartott a felhasználói visszajelzésekre való reagálás. A v2.0-ban ehelyett napok alatt hozzáadhatjuk az új alkalmazások vagy funkciók támogatását.

Negyedszer: hiteles, érdemi előrelépés afelé, hogy egy bizalom-csökkentett és decentralizált rendszerré váljunk. Bár a valódi decentralizáció még egy kicsit messze van, sikeresen áttértünk arra, hogy teljes mértékben ne legyen bizalmi rendszer, és lefektettük az alapokat a Lightning-stílusú multihop megvalósításához túl sok jövőbeli protokollváltoztatás nélkül. Ezt részletesebben a Trust Assumptions alább tárgyaljuk.

v2.0 Connext a csúcspontja az összes fantasztikus visszajelzésnek, amit eddig kaptunk a közösségtől, és egyben az első lépés egy olyan Ethereum kettes réteg felé, amely készen áll a mindennapi használatra.

Köszönjük mindenkinek, hogy részesei voltatok az eddigi csodálatos utazásunknak!

Bizalmi feltételezések

Amikor elindítottuk a Dai Cardot a Connext v1-en, felsoroltuk a hálózatunk főbb bizalmi feltételezéseit. Ezúttal a régi feltételezéseinket tekintjük át, amellett, hogy kitérünk a frissítéssel bevezetett újakra is.

A menet közbeni egyes fizetések letétbe helyezettek voltak

A v1-ben a felhasználói pénzeszközök mindig nem voltak letétbe helyezettek, de magukat az átutalásokat menet közben néha a hub tartotta. Ez különösen igaz volt a feltételesebb átutalásokra, például a Link kifizetésekre vagy az offline címzetteknek történő átutalásokra.

A v2.0-ban minden átutalás teljes mértékben nem letétbe helyezhető, még menet közben is. A hub nem képes ellopni a pénzedet. Ez azért lehetséges, mert a v2.0 natívan támogatja az általános állapotfrissítéseket a csatornákban, ami sokkal nagyobb rugalmasságot biztosít számukra.

A hub tartotta az állapot “fő” példányát, és az ügyfelek alapértelmezés szerint nem készítettek biztonsági másolatot az állapotról

A v1-ben, ha offline állapotba kerültél, a hub volt az egyetlen entitás, amely megőrizte az állapotodat. Ez nagyszerű volt az eszközök közötti kompatibilitás szempontjából, de azt jelentette, hogy a hubtól függött, hogy pontosan visszaállítja-e az állapotát, és hogy igazat mond-e a viták során. Eredetileg ezt az állapot IPFS-en történő mentésével akartuk megoldani, de azóta úgy döntöttünk, hogy más irányba megyünk.

A v2.0-ban az állapot tárolása és mentése a tárcára van bízva. A felhasználónak rendelkeznie kell az állapot helyi másolatával ahhoz, hogy egy csatornát futtasson, ami az állapot tartós “munkamásolataként” működik, de a tárcák további távoli biztonsági másolatokat is létrehozhatnak és valószínűleg létre is kell hozniuk. Az ügyfelek alapértelmezés szerint már nem állítják vissza az állapotot a hubból, bár opcionálisan megtehetik, ha a végfelhasználó úgy dönt. Azt sem követeljük meg többé, hogy a csatornák vitáit csak a csatorna tulajdonosa oldja meg – ez lehetővé teszi a pénztárca szolgáltatók számára, hogy Watchtowerként működjenek a felhasználóik számára.

A frissítések http-n keresztül történnek és cenzúrázhatóak

A v1-ben a hub egy REST szerver volt, és az ügyfelek http POST-okon keresztül kommunikálták a frissítéseket. Ez jó taktika volt az egyszerűség érdekében, de azt jelentette, hogy a hub egy nehézkes kérésalapú áramlást írt elő az állapotok frissítéséhez, és cenzúrázni tudta ezeket a frissítéseket.

A v2.0-ban áttértünk a NATS-re – egy rendkívül skálázható, könnyű, nyílt forráskódú, p2p üzenetküldő rendszerre. A NATS lehetővé teszi, hogy a hub eltávolodjon a http-kérés paradigmától, lehetővé téve, hogy az állapot több független másolata legyen. Sajnos a megfelelő működéshez még mindig szükség van egy üzenetküldő kiszolgáló implementálására (jelenleg a hubon található). Ez azt jelenti, hogy bár most már p2p, a központosított v2.0 hubban lévő üzenetek még mindig cenzúrázhatóak, mint a v1-ben.

A döntés, hogy kifejezetten a NATS-t használjuk, azonban egy lépés a probléma megoldása felé. A NATS támogatja a decentralizált (hálós) üzenetküldést sok üzenetküldő szerver klaszterezésével. Ez azt jelenti, hogy klaszterezett NATS példányokat szállíthatunk a Connext csomópontok részeként az esetleges decentralizált hálózatunkban, hogy ezzel együtt decentralizáljuk az üzenetküldő rétegünket.

Az átutalások a hubon keresztül történnek és cenzúrázhatóak

A v1-ben minden felhasználó letétbe helyezett csatornákat a hubon keresztül, majd a hubon keresztül továbbította az átutalásokat egymásnak (hasonlóan a 0x relayerek működéséhez). Ez egy bootstrapping technika volt egy megbízható, könnyen iterálható rendszer létrehozásához, miközben felhasználói adatokat gyűjtöttünk és különböző felhasználási eseteket teszteltünk. Ez azonban azt is jelentette, hogy a hubot cenzúrázni, DDoS-olni vagy leállítani lehetett, ami a fizetési szolgáltatásunkat offline állapotba hozta (bár a felhasználói pénzek nem vesznek el!).

A v2.0 induláskor ugyanezt a paradigmát használja, és továbbra is cenzúrázható. Még mindig van munka, amit el kell végezni, mielőtt valóban decentralizált hálózattá válhatunk. Azonban a p2p üzenetküldés és az általánosított állapot hozzáadása hatalmas lépés a jó irányba. Most már gyorsan iterálhatunk bővíthetőbb átviteli protokollokat anélkül, hogy a rendszer teljes újraírását vagy az interfészek drasztikus frissítését kellene elvégeznünk.

Az ügyfél proxyként a hub interfészén keresztül fér hozzá a Redlockhoz

A felhasználói állapot tárolásának decentralizálásával bevezettük az állapot egyidejű frissítésével kapcsolatos komplexitást. A centralizált szervereken az egyidejűséget az állapot zárolásával/feloldásával kezelik minden egyes műveletnél. A mi elosztott paradigmánkhoz a Redis elosztott zárolásait integráltuk a hubba. Sajnos a Redis nem natívan támogatott a böngészőkben, és a Webdis, a böngészőalapú Redis-interfész nem támogatja a Redlockot.

A hatékony szállítás érdekében egy proxy-interfészt építettünk, amelyet a hub hosztol, hogy az ügyfél lezárhassa/feloldhassa az állapotát. Rövid- és középtávon várhatóan újraimplementáljuk vagy módosítjuk a Webdis-t, hogy az elosztott zárolást is használhassa.

Technikai részletek

A szerződések független auditálása megtörtént:

• Auditjelentés készítése
• Decenter Audit Report

Mainnet szerződések:

• 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

Szerződéskód:

• Counterfactual Funding Protocol szerződések
• Counterfactual Adjudication szerződések