Connext v2.0 jest w Mainnet

tl;dr: Wysłaliśmy to! 🚢

v2.0 jest niesamowity, ponieważ: podwaja to, co ludzie kochają z v1, natywnie wspiera portfele, łagodzi bolączki v1 i poprawia założenia dotyczące zaufania.

Portale i dApps mogą zacząć działać zgodnie z Quick Start w naszych dokumentach. Karta Dai Work-in-Progress (Rinkeby) jest dostępna tutaj.

Po długich dwóch miesiącach testów Rinkeby, audytów i poprawiania błędów, wdrożyliśmy v2.0 Connext! 🌟

• Najlepszym miejscem do rozpoczęcia pracy jest przewodnik Szybki start w naszych dokumentach.
• Porozmawiaj z nami na naszym discordzie, jeśli masz jakieś pytania.
• Kod jest dostępny pod adresem: https://github.com/ConnextProject/indra
• Work in progress Rinkeby v2.0 Dai Card is live at: https://rinkeby.indra.connext.network

Co z kartą mainnet v2.0 Dai? Wkrótce! Pracujemy nad tym, aby upewnić się, że nie ma żadnych błędów w UI, które mogłyby spowodować utratę środków przez użytkowników.

V2.0 działa na Counterfactual. Kiedy zintegrujecie v2.0, będziecie również ostatecznie wspierać State Channels framework – ujednolicony standard dla kanałów na Ethereum.

Jak to działa?

Sprawdźcie nasz post w sieci testowej, aby zapoznać się z technologią!

Dlaczego V2.0 ma znaczenie?

Dwa lata temu rozpoczęliśmy działalność Connext z prostym pytaniem:

„Jak możemy wprowadzić 1 miliard użytkowników do Ethereum?”

To pytanie doprowadziło nas przez wiele iteracji produktu na styku skalowalności, UX i transferu Ethereum. Postawiliśmy hipotezę, że użytkownicy końcowi chcą bezproblemowego i spójnego doświadczenia w swoich portfelach i aplikacjach, niezależnie od tego, czy mają Ethereum na gaz, lub jak zatłoczony jest blockchain, a nawet jaki sidechain/plasmachain/shard są na.

Wiedzieliśmy, że trafiliśmy na coś ważnego, kiedy wysłaliśmy kartę Dai v1 na początku tego roku i zobaczyliśmy reakcje takie jak ta:

Budując v2.0, nasze cele były proste. Po pierwsze: podwoić to, co użytkownicy już pokochali w systemie Connext. Oznaczało to dalsze uproszczenie integracji Connext, ponowne wdrożenie łatwej onboarding poprzez linki jako domyślne, i – co najważniejsze – kontynuowanie pracy nad tym, aby nasze już magiczne transfery były jeszcze szybsze.

Po drugie: przearchiwizować Connext jako sieć przede wszystkim portfel-to-wallet, do której dApps mogą następnie podłączyć się dla swoich specyficznych przypadków użycia. Stwierdziliśmy, że portfele uwielbiają doświadczenie użytkownika, które umożliwiła v1, więc przeprojektowaliśmy klienta Connext, aby działał znacznie płynniej z istniejącymi paradygmatami rozwoju portfeli do zarządzania kluczami i przechowywania.

Po trzecie: przemyśl nasze podejście do największych problemów użytkowników. W v1, najtrudniejszą częścią Connext był, co nie jest zaskakujące, proces wpłaty do i wypłaty z kanału onchain. W wersji 2.0 nie tylko uprościliśmy proces wpłaty/wypłaty, ale także umożliwiliśmy portfelom wstrzyknięcie dostawcy dla kanału użytkownika do dApp, usuwając potrzebę wpłaty na więcej niż jeden kanał. Kolejnym wielkim bólem głowy w v1 była nieelastyczność protokołu, co oznaczało, że reagowanie na opinie użytkowników trwało tygodnie lub miesiące. W v2.0, możemy zamiast tego dodać wsparcie dla nowych aplikacji lub funkcji w ciągu kilku dni.

Po czwarte: zrobić wiarygodny, znaczący postęp w kierunku stania się bardziej zminimalizowanym zaufaniem i zdecentralizowanym systemem. Podczas gdy do prawdziwej decentralizacji jeszcze trochę brakuje, udało nam się przejść do bycia w pełni noncustodial i położyliśmy podwaliny pod wdrożenie multihop w stylu Lightning bez zbyt wielu przyszłych zmian w protokole. Omawiamy to bardziej szczegółowo w Założeniach zaufania poniżej.

v2.0 Connext jest kulminacją wszystkich wspaniałych opinii, które otrzymaliśmy do tej pory od społeczności, a także jest pierwszym krokiem w kierunku warstwy drugiej Ethereum, która jest gotowa do codziennego użytku.

Dziękujemy wszystkim za bycie częścią naszej wspaniałej podróży do tej pory!

Założenia zaufania

Kiedy uruchomiliśmy kartę Dai na v1 Connext, wymieniliśmy główne założenia zaufania naszej sieci. Tym razem przejrzymy nasze stare założenia oprócz omówienia nowych, wprowadzonych w tej aktualizacji.

Podczas lotu, niektóre płatności były przechowywane

W v1, środki użytkownika były zawsze niepowiernicze, ale same przelewy, podczas lotu, były czasami przechowywane przez hub. Było to szczególnie prawdziwe dla bardziej warunkowych przelewów, takich jak płatności za linki lub przelewy do odbiorców offline.

W v2.0, wszystkie przelewy są w pełni noncustodial, nawet gdy w locie. Hub nie ma możliwości kradzieży Twoich środków. Jest to możliwe, ponieważ v2.0 natywnie obsługuje uogólnione aktualizacje stanu w kanałach, dając im znacznie większą elastyczność.

Hub posiadał „główną” kopię stanu, a klienci nie tworzyli domyślnie kopii zapasowych stanu

W v1, jeśli wyszedłeś offline, hub był jedynym podmiotem, który utrzymywał twój stan. Było to świetne dla kompatybilności między urządzeniami, ale oznaczało, że polegałeś na hubie, aby przywrócić swój stan dokładnie i być prawdomównym podczas sporów. Pierwotnie zamierzaliśmy rozwiązać ten problem poprzez tworzenie kopii zapasowych stanu na IPFS, ale od tego czasu zdecydowaliśmy się pójść w innym kierunku.

W wersji 2.0, przechowywanie stanu i tworzenie kopii zapasowych jest pozostawione portfelowi. Użytkownik musi mieć lokalną kopię stanu, aby uruchomić kanał, który działa jako trwała „kopia robocza” stanu, ale portfele mogą i prawdopodobnie powinny tworzyć dalsze zdalne kopie zapasowe. Klienci nie odzyskują już domyślnie stanu z huba, choć mogą to robić opcjonalnie, jeśli użytkownik końcowy tak zdecyduje. Nie wymagamy już także, aby spory na kanale były rozwiązywane tylko przez właściciela kanału – to umożliwia dostawcom portfeli działanie jako Strażnicy dla swoich użytkowników.

Aktualizacje odbywają się przez http i są cenzurowane

W v1, hub był serwerem REST, a klienci przekazywali aktualizacje przez http POSTs. Była to dobra taktyka, aby zachować prostotę, ale oznaczała, że hub wymagał skomplikowanego przepływu opartego na żądaniach, aby zaktualizować stany i mógł cenzurować te aktualizacje.

W v2.0 przenieśliśmy się do NATS – wysoce skalowalnego, lekkiego, otwartego systemu przesyłania wiadomości p2p. NATS pozwala nam odejść od paradygmatu http-request, dzięki czemu możliwe jest posiadanie wielu niezależnych kopii stanu. Niestety, nadal wymaga to od nas implementacji serwera komunikacyjnego (obecnie hostowanego przez hub) do poprawnego działania. Oznacza to, że podczas gdy wiadomości są teraz p2p, wiadomości w scentralizowanym hubie v2.0 są nadal cenzurowane jak w v1.

Decyzja o użyciu NATS jest krokiem w kierunku rozwiązania tego problemu. NATS wspiera zdecentralizowane (mesh) przesyłanie wiadomości poprzez grupowanie wielu serwerów wiadomości razem. Oznacza to, że możemy wysłać sklastrowane instancje NATS jako część węzłów Connext w naszej ewentualnej zdecentralizowanej sieci, aby zdecentralizować naszą warstwę komunikacyjną w tandemie.

Przelewy odbywają się przez hub i są cenzurowane

W v1, każdy użytkownik składał się na kanały z hubem, a następnie kierował przelewy do siebie nawzajem przez hub (podobnie do tego jak działają przekaźniki 0x). To była technika bootstrappingu, aby stworzyć niezawodny, łatwo iterowalny system, podczas gdy my zbieraliśmy dane o użytkownikach i testowaliśmy wiele różnych przypadków użycia. Oznaczało to jednak również, że nasz hub mógł zostać ocenzurowany, DDoS’d lub zamknięty, przez co nasza usługa płatnicza została wyłączona (ale żadne fundusze użytkowników nie zostałyby utracone!).

W momencie uruchomienia, v2.0 używa tego samego paradygmatu i nadal może być ocenzurowany. Nadal jest praca, która musi zostać wykonana zanim będziemy mogli być prawdziwie zdecentralizowaną siecią. Jednak dodanie przesyłania wiadomości p2p i uogólnionego stanu jest ogromnym krokiem we właściwym kierunku. Możemy teraz szybko iterować nad bardziej rozszerzalnymi protokołami transferu bez potrzeby pełnego przepisywania systemu lub drastycznego aktualizowania interfejsów.

Klient proxy przez interfejs huba, aby uzyskać dostęp do Redlocka

Decentralizując przechowywanie stanu użytkownika, wprowadziliśmy złożoność związaną ze współbieżnym aktualizowaniem stanu. W scentralizowanych serwerach, współbieżność jest obsługiwana przez blokowanie/odblokowywanie stanu przy każdej operacji. Dla naszego rozproszonego paradygmatu, zintegrowaliśmy w hubie rozproszone zamki Redisa. Niestety, Redis nie jest natywnie obsługiwany w przeglądarkach, a Webdis, interfejs Redis oparty na przeglądarce, nie obsługuje Redlock.

W interesie wydajnej wysyłki, zbudowaliśmy interfejs proxy hostowany przez koncentrator dla klienta, aby zablokować/odblokować ich stan. W krótkim lub średnim terminie spodziewamy się ponownie wdrożyć lub zmodyfikować Webdis, aby również używać rozproszonego blokowania.

Dane techniczne

Kontrakty zostały niezależnie skontrolowane:

• Provide Audit Report
• Decenter Audit Report

Kontrakty Mainnet:

• 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

Kod umowy:

• Kontrakty Counterfactual Funding Protocol
• Kontrakty Counterfactual Adjudication

.