Connext v2.0 je na Mainnetu

tl;dr: Odeslali jsme to! 🚢

V2.0 je úžasná, protože: zdvojnásobuje to, co lidé milují z v1, nativně podporuje peněženky, zmírňuje bolestivé body v1 a zlepšuje předpoklady důvěryhodnosti.

Peněženky a dAppy mohou začít podle stručného návodu v našich dokumentech. Dai karta ve stavu rozpracovanosti (Rinkeby) je k dispozici zde.

Po dlouhých dvou měsících testování Rinkeby, auditů a oprav chyb jsme nasadili verzi Connext v2.0! 🌟

• Nejlepším místem, kde do toho můžete skočit, je průvodce rychlým spuštěním v našich dokumentech.
• Přijďte si s námi popovídat na náš discord, pokud máte nějaké otázky.
• Kód je k dispozici na adrese: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card je v provozu na adrese: https://rinkeby.indra.connext.network

Co takhle mainnet v2.0 Dai Card? Již brzy! Pracujeme na tom, aby v uživatelském rozhraní nebyly žádné zádrhele, kvůli kterým by uživatelé mohli přijít o peníze.

V2.0 běží na Counterfactual. Když integrujete v2.0, budete nakonec podporovat i framework State Channels – jednotný standard pro kanály na Ethereu.

Jak to funguje?

Podívejte se na náš příspěvek na testnetu, kde najdete přehled techniky!

Proč je V2.0 důležitá?

Před dvěma lety jsme začali Connext s jednoduchou otázkou:

„Jak můžeme k Ethereu přivést 1 miliardu uživatelů?“

Tato otázka nás vedla přes spoustu produktových iterací na pomezí škálovatelnosti, UX a přenosů Etherea. Předpokládali jsme, že koncoví uživatelé chtějí bezproblémový a konzistentní zážitek ve svých peněženkách a aplikacích bez ohledu na to, zda mají Eth za plyn, nebo jak moc je blockchain přetížený, nebo dokonce na jakém sidechainu/plasmachainu/shardu se nacházejí.

Věděli jsme, že jsme narazili na něco důležitého, když jsme na začátku tohoto roku dodali Dai Card v1 a viděli jsme reakce, jako je tato:

Při vytváření verze 2.0 byly naše cíle jednoduché. Za prvé: zdvojnásobit to, co si uživatelé na Connext již oblíbili. To znamenalo ještě více zjednodušit integrace Connext, znovu zavést snadný onboarding prostřednictvím odkazů jako výchozí a – což je nejdůležitější – pokračovat v práci na tom, aby naše již tak kouzelné převody byly ještě rychlejší.

Druhé: rearchitekovat Connext jako primárně síť mezi peněženkami, na kterou se pak mohou napojit dApps pro své specifické případy použití. Zjistili jsme, že peněženkám se líbí uživatelské prostředí, které v1 umožňuje, a proto jsme klienta Connext přepracovali tak, aby mnohem lépe spolupracoval se stávajícími paradigmaty vývoje peněženek pro správu a ukládání klíčů.

Zatřetí: přehodnotili jsme náš přístup k největším bolestem uživatelů. Ve verzi v1 byl nepřekvapivě nejobtížnější částí systému Connext proces vkladu do kanálu onchain a výběru z něj. Ve verzi 2.0 jsme nejen zjednodušili vklady/výběry, ale také jsme peněženkám hodně umožnili injektovat poskytovatele pro kanál uživatele do dApp , čímž jsme odstranili potřebu uživatelů vkládat do více než jednoho kanálu na začátku. Další velkou bolestí hlavy ve verzi 1 byla nepružnost protokolu, což znamenalo, že reakce na zpětnou vazbu uživatelů trvala týdny nebo měsíce. Ve verzi 2.0 můžeme místo toho přidat podporu nových aplikací nebo funkcí během několika dní.

Za čtvrté: udělat věrohodný a smysluplný pokrok směrem k tomu, abychom se stali důvěryhodnějším a decentralizovanějším systémem. Ačkoli skutečná decentralizace je ještě trochu daleko, úspěšně jsme se posunuli k tomu, abychom byli plně necustodiální, a položili jsme základy pro implementaci multihopu ve stylu Lightningu bez příliš mnoha budoucích změn protokolu. Podrobněji se tomu věnujeme níže v části Předpoklady důvěryhodnosti.

V2.0 Connext je vyvrcholením veškeré úžasné zpětné vazby, kterou jsme dosud od komunity obdrželi, a je také prvním krokem k druhé vrstvě Etherea, která je připravena ke každodennímu používání.

Děkujeme vám všem, že jste byli součástí naší dosavadní úžasné cesty!

Předpoklady důvěryhodnosti

Když jsme uvedli kartu Dai na v1 Connext, uvedli jsme hlavní předpoklady důvěryhodnosti naší sítě. Tentokrát si kromě pokrytí nových předpokladů zavedených v této aktualizaci projdeme i naše staré předpoklady.

Za letu byly některé platby opatrovnické

V verzi v1 byly prostředky uživatelů vždy neopatrovnické, ale samotné převody za letu byly někdy v držení rozbočovače. To se týkalo zejména podmíněnějších převodů, jako jsou platby za odkazy nebo převody offline příjemcům.

V verzi v2.0 jsou všechny převody plně neuschovatelné, i když jsou za letu. Rozbočovač nemá žádnou možnost ukrást vaše prostředky. To je možné, protože verze v2.0 nativně podporuje generalizované aktualizace stavu v kanálech, což jim dává mnohem větší flexibilitu.

Hub držel „hlavní“ kopii stavu a klienti ve výchozím nastavení stav nezálohovali

V verzi v1, pokud jste přešli do režimu offline, byl hub jedinou entitou, která uchovávala váš stav. To bylo skvělé pro kompatibilitu mezi zařízeními, ale znamenalo to, že jste se spoléhali na to, že rozbočovač obnoví váš stav přesně a že bude při sporech pravdivý. Původně jsme to chtěli vyřešit zálohováním stavu na IPFS, ale od té doby jsme se rozhodli jít jiným směrem.

V verzi 2.0 je ukládání a zálohování stavu ponecháno na peněžence. Uživatel musí mít místní kopii stavu, aby mohl spustit kanál, který funguje jako trvalá „pracovní kopie“ stavu, ale peněženky mohou a pravděpodobně by měly vytvářet další vzdálené zálohy. Klienti již ve výchozím nastavení neobnovují stav z centra, ačkoli tak mohou volitelně činit, pokud se tak koncový uživatel rozhodne. Také již nevyžadujeme, aby spory v kanálech řešil pouze jejich vlastník – díky tomu mohou poskytovatelé peněženek fungovat jako hlídací věže pro své uživatele.

Aktualizace probíhají přes http a jsou cenzurovatelné

V v1 byl hub REST server a klienti si aktualizace sdělovali pomocí http POSTů. To byla dobrá taktika, jak udržet věci jednoduché, ale znamenalo to, že rozbočovač nařizoval neohrabaný tok založený na požadavcích na aktualizaci stavů a mohl tyto aktualizace cenzurovat.

V verzi 2.0 jsme přešli na NATS – vysoce škálovatelný, odlehčený, open source, p2p systém pro zasílání zpráv. NATS nám umožňuje přesunout centrum z paradigmatu http-request, což umožňuje mít více nezávislých kopií stavu. Bohužel stále vyžaduje, abychom implementovali server pro zasílání zpráv (v současné době hostovaný v rozbočovači), aby správně fungoval. To znamená, že ačkoli jsou nyní p2p, zprávy v centralizovaném rozbočovači v2.0 jsou stále cenzurovatelné jako v v1.

Rozhodnutí použít konkrétně NATS je však krokem k vyřešení tohoto problému. NATS podporuje decentralizované (mesh) zasílání zpráv tím, že sdružuje mnoho serverů pro zasílání zpráv. To znamená, že můžeme dodávat clusterové instance NATS jako součást uzlů Connext v naší případné decentralizované síti, abychom decentralizovali naši vrstvu pro zasílání zpráv v tandemu.

Přenosy probíhají přes rozbočovač a jsou cenzurovatelné

V v1 každý uživatel ukládal do kanálů s rozbočovačem a pak směroval přenosy mezi sebou přes rozbočovač (podobně jako fungují relayery 0x). Jednalo se o zaváděcí techniku k vytvoření spolehlivého, snadno iterovatelného systému, zatímco jsme sbírali data uživatelů a testovali různé případy použití. To však také znamenalo, že náš hub mohl být cenzurován, napaden DDoS nebo odstaven, čímž by se naše platební služba ocitla mimo provoz (ačkoli by se neztratily žádné prostředky uživatelů!).

Při spuštění verze v2.0 používá stejné paradigma a stále může být cenzurována. Ještě je třeba udělat spoustu práce, než se staneme skutečně decentralizovanou sítí. Nicméně přidání p2p zpráv a zobecněného stavu je obrovský krok správným směrem. Nyní můžeme rychle iterovat na rozšiřitelnější přenosové protokoly, aniž bychom museli kompletně přepisovat systém nebo drasticky aktualizovat rozhraní.

Klient proxy přes rozhraní hubu přistupuje k Redlocku

Decentralizací ukládání stavu uživatele jsme zavedli složitost spojenou se současnou aktualizací stavu. V centralizovaných serverech je souběžnost řešena zamykáním/odemykáním stavu při každé operaci. Pro naše distribuované paradigma jsme do rozbočovače integrovali distribuované zámky Redis. Bohužel Redis není nativně podporován v prohlížečích a Webdis, rozhraní Redis založené na prohlížeči, nepodporuje Redlock.

V zájmu efektivní přepravy jsme vytvořili proxy rozhraní hostované hubem, aby klient mohl zamykat/odemykat svůj stav. V krátkodobém až střednědobém horizontu očekáváme reimplementaci nebo úpravu Webdis tak, aby používal také distribuované zamykání.

Technické podrobnosti

Smlouvy byly nezávisle auditovány:

• Provide Audit Report
• Decenter Audit Report

Smlouvy v hlavní síti:

• 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

Kód smlouvy:

• Smlouvy o kontrafaktuálním protokolu financování
• Smlouvy o kontrafaktuálním rozhodování