Connext v2.0 este pe Mainnet

tl;dr: Am livrat chestia! 🚢

v2.0 este grozav pentru că: dublează ceea ce oamenii iubesc de la v1, suportă în mod nativ portofele, ameliorează punctele dureroase ale v1 și îmbunătățește ipotezele de încredere.

Wallets și dApps pot începe urmând Quick Start în documentele noastre. Un card Dai Work-in-progress (Rinkeby) este disponibil aici.

După o lungă perioadă de două luni de testare Rinkeby, audituri și remediere a erorilor, am implementat versiunea v2.0 a Connext! 🌟

• Cel mai bun loc pentru a intra în joc este ghidul Quick Start din documentația noastră.
• Veniți să vorbiți cu noi în discordul nostru dacă aveți întrebări.
• Codul este disponibil la: https://github.com/ConnextProject/indra
• Lucrări în curs de desfășurare Rinkeby v2.0 Dai Card este în direct la: https://rinkeby.indra.connext.network

Ce zici de un Mainnet v2.0 Dai Card? În curând! Lucrăm pentru a ne asigura că nu există gotchas UI care ar putea face ca utilizatorii să piardă fonduri.

V2.0 rulează pe Counterfactual. Când integrați v2.0, veți sprijini în cele din urmă și cadrul State Channels – standardul unificat pentru canale pe Ethereum.

Cum funcționează?

Consultați postul nostru testnet pentru o prezentare generală a tehnologiei!

De ce contează V2.0?

Cu doi ani în urmă, am început Connext cu o întrebare simplă:

„Cum putem aduce 1 miliard de utilizatori la Ethereum?”

Această întrebare ne-a condus printr-o mulțime de iterații de produs la confluența dintre scalabilitate, UX și transferuri Ethereum. Am emis ipoteza că utilizatorii finali doresc o experiență continuă și consecventă în portofelele și aplicațiile lor, indiferent dacă au Etheret pentru gaz, sau cât de congestionat este blockchain-ul, sau chiar pe ce sidechain/plasmachain/shard se află.

Am știut că am dat peste ceva important atunci când am livrat v1 Dai Card la începutul acestui an și am văzut reacții precum aceasta:

Când am construit v2.0, obiectivele noastre au fost simple. În primul rând: să dublăm ceea ce utilizatorii iubesc deja la Connext. Acest lucru a însemnat simplificarea în continuare a integrărilor Connext, reimplementarea unei îmbarcări ușoare prin link-uri în mod implicit și – cel mai important – continuarea eforturilor de a face transferurile noastre deja magice și mai rapide.

Secundar: să re-arhitectăm Connext ca o rețea în primul rând de la portofel la portofel, la care dApps se pot agăța apoi pentru cazurile lor de utilizare specifice. Am constatat că portofelele au apreciat experiența utilizatorului pe care v1 a permis-o, așa că am reproiectat clientul Connext pentru a funcționa mult mai ușor cu paradigmele existente de dezvoltare a portofelelor pentru gestionarea și stocarea cheilor.

În al treilea rând: regândirea abordării noastre față de cele mai mari puncte de durere ale utilizatorilor. În v1, cea mai dificilă parte a Connext a fost, în mod nesurprinzător, procesul de depunere în și retragere din canalul onchain. În v2.0, nu numai că am simplificat depunerea/retragerea, dar am făcut, de asemenea, mult mai posibil ca portofelele să injecteze un furnizor pentru canalul unui utilizator într-o dApp , eliminând necesitatea ca utilizatorii să depună în mai mult de un canal pentru început. O altă mare bătaie de cap în v1 a fost inflexibilitatea protocolului, ceea ce înseamnă că era nevoie de săptămâni sau luni pentru a reacționa la feedback-ul utilizatorilor. În v2.0, putem, în schimb, să adăugăm suport pentru noi aplicații sau caracteristici în câteva zile.

Al patrulea: să facem progrese credibile și semnificative pentru a deveni un sistem mai puțin încrezător și mai descentralizat. În timp ce adevărata descentralizare este încă un pic mai departe, am trecut cu succes la a fi complet noncustodiali și am pus bazele pentru implementarea multihopului de tip Lightning fără prea multe modificări viitoare ale protocolului. Acoperim acest aspect mai detaliat în Ipotezele de încredere de mai jos.

v2.0 a Connext este punctul culminant al tuturor reacțiilor minunate pe care le-am primit până acum din partea comunității și este, de asemenea, primul pas către un strat Ethereum doi care este gata pentru utilizarea zilnică.

Vă mulțumim tuturor pentru că ați făcut parte din minunata noastră călătorie de până acum!

Imagini de încredere

Când am lansat Dai Card pe v1 de Connext, am enumerat principalele ipoteze de încredere ale rețelei noastre. De data aceasta, vom trece în revistă vechile noastre ipoteze, pe lângă faptul că le vom acoperi pe cele noi introduse în această actualizare.

În timpul zborului, unele plăți erau custodiale

În v1, fondurile utilizatorilor erau întotdeauna necustodiale, dar transferurile în sine, în timpul zborului, erau uneori deținute de hub. Acest lucru era valabil în special pentru transferurile mai condiționate, cum ar fi plățile Link sau transferurile către destinatarii offline.

În v2.0, toate transferurile sunt complet noncustodiale, chiar și atunci când sunt în zbor. Hub-ul nu are capacitatea de a vă fura fondurile. Acest lucru este posibil deoarece v2.0 suportă în mod nativ actualizări generalizate ale stării în canale, oferindu-le mult mai multă flexibilitate.

Hub-ul deținea copia „master” a stării, iar clienții nu făceau în mod implicit o copie de rezervă a stării

În v1, dacă erați offline, hub-ul era singura entitate care vă persista starea. Acest lucru era grozav pentru compatibilitatea între dispozitive, dar însemna că vă bazați pe hub pentru a vă restabili starea cu acuratețe și pentru a fi sincer în timpul disputelor. Inițial am intenționat să rezolvăm acest lucru prin salvarea stării pe IPFS, dar de atunci am decis să mergem într-o direcție diferită.

În v2.0, stocarea și salvarea stării este lăsată la latitudinea portofelului. Utilizatorul trebuie să aibă o copie locală a stării pentru a rula un canal, care acționează ca o „copie de lucru” persistentă a stării, dar portofelele pot și probabil ar trebui să creeze și alte copii de rezervă la distanță. Clienții nu mai recuperează starea de la hub în mod implicit, deși pot face acest lucru în mod opțional, dacă utilizatorul final alege. De asemenea, nu mai solicităm ca disputele de canal să fie rezolvate doar de către proprietarul canalului – acest lucru face posibil ca furnizorii de portofele să acționeze ca Turnuri de Control pentru utilizatorii lor.

Actualizările au loc prin http și sunt cenzurabile

În v1, hub-ul era un server REST, iar clienții comunicau actualizările prin POST-uri http. Aceasta a fost o tactică bună pentru a păstra lucrurile simple, dar a însemnat că hub-ul a impus un flux greoi bazat pe cereri pentru a actualiza stările și ar putea cenzura aceste actualizări.

În v2.0, am trecut la NATS – un sistem de mesagerie p2p extrem de scalabil, ușor, cu sursă deschisă, cu sursă deschisă. NATS ne permite să mutăm hub-ul departe de paradigma http-request, făcând posibilă existența mai multor copii independente ale stării. Din nefericire, pentru a funcționa în mod corespunzător, este încă necesar să implementăm un server de mesagerie (găzduit în prezent de hub). Acest lucru înseamnă că, deși acum sunt p2p, mesajele din hub-ul centralizat v2.0 sunt încă cenzurabile ca în v1.

Decizia de a folosi NATS în mod specific este totuși un pas spre rezolvarea acestei probleme. NATS suportă mesageria descentralizată (mesh) prin gruparea mai multor servere de mesagerie împreună. Acest lucru înseamnă este că putem livra instanțe NATS grupate ca parte a nodurilor Connext în eventuala noastră rețea descentralizată, pentru a descentraliza stratul nostru de mesagerie în tandem.

Transferurile se realizează prin hub și sunt cenzurabile

În v1, fiecare utilizator a depus în canale cu hub-ul și apoi a direcționat transferurile unul către celălalt prin hub (similar cu modul în care funcționează releele 0x). Aceasta a fost o tehnică de bootstrap pentru a crea un sistem fiabil și ușor de iterat în timp ce am colectat date despre utilizatori și am testat o varietate de cazuri de utilizare diferite. Totuși, acest lucru a însemnat, de asemenea, că hub-ul nostru putea fi cenzurat, DDoS’d sau închis, punând serviciul nostru de plată offline (deși nu s-ar fi pierdut fondurile utilizatorilor!).

La lansare, v2.0 folosește aceeași paradigmă și poate fi în continuare cenzurat. Mai este încă mult de lucru înainte de a putea fi o rețea cu adevărat descentralizată. Cu toate acestea, adăugarea mesageriei p2p și a statului generalizat este un pas uriaș în direcția cea bună. Acum putem itera rapid pe protocoale de transfer mai extensibile fără a fi nevoie să rescriem complet sistemul sau să actualizăm drastic interfețele.

Client proxies prin interfața hub-ului pentru a accesa Redlock

Prin descentralizarea stocării stării utilizatorului, am introdus complexitatea legată de actualizarea concomitentă a stării. În serverele centralizate, concurența este gestionată prin blocarea/ deblocarea stării la fiecare operațiune. Pentru paradigma noastră distribuită, am integrat blocajele distribuite ale Redis în hub. Din nefericire, Redis nu este suportat nativ în browsere, iar Webdis, interfața Redis bazată pe browser, nu suportă Redlock.

În interesul unei livrări eficiente, am construit o interfață proxy găzduită de hub pentru ca clientul să își blocheze/ deblocheze starea. Pe termen scurt sau mediu, ne așteptăm să reimplementăm sau să modificăm Webdis pentru a utiliza și blocarea distribuită.

Detalii tehnice

Contractele au fost auditate în mod independent:

• Provide Audit Report
• Decenter Audit Report

Contracte de rețea principală:

• ChallengeRegistry.sol
• ConditionalTransactionDelegateTarget.sol
• CoinBalanceRefundApp.sol
• MultiAssetMultiPartyCoinTransferInterpreter.sol
• IdentityApp.sol
• MinimumViableMultisig.sol
• MinimumViableMultisig.sol (singleton)
• ProxyFactory.sol
• SingleAssetSingleAssetTwoPartyCoinTransferInterpreter.sol
• TimeLockedPassThrough.sol
• TwoPartyFixedOutcomeInterpreterter.sol
• TwoPartyFixedOutcomeFromVirtualAppInterpreter.sol
• SimpleTwoPartySwapApp.sol
• SimpleLinkedTransferApp.sol
• SimpleTransferApp.sol

Codul contractului:

• Contracte de protocol de finanțare contrafactuală
• Contracte de adjudecare contrafactuală

.