Connext v2.0 è su Mainnet

tl;dr: Abbiamo spedito la cosa! 🚢

La v2.0 è fantastica perché: raddoppia ciò che la gente ama della v1, supporta nativamente i portafogli, allevia i punti dolenti della v1 e migliora le ipotesi di fiducia.

I portafogli e le dApp possono iniziare seguendo il Quick Start nei nostri documenti. Un work-in-progress (Rinkeby) Dai Card è disponibile qui.

Dopo due lunghi mesi di test Rinkeby, audit e bugfixing, abbiamo distribuito la v2.0 di Connext! 🌟

• Il posto migliore per iniziare è la guida rapida nei nostri documenti.
• Venite a parlare con noi nel nostro discord se avete delle domande.
• Il codice è disponibile presso: https://github.com/ConnextProject/indra
• Lavoro in corso Rinkeby v2.0 Dai Card è live a: https://rinkeby.indra.connext.network

Che ne dici di una Dai Card v2.0 mainnet? Presto! Stiamo lavorando per assicurarci che non ci siano errori nell’interfaccia utente che potrebbero far perdere fondi agli utenti.

V2.0 funziona su Counterfactual. Quando integrerai la v2.0, alla fine supporterai anche il framework State Channels – lo standard unificato per i canali su Ethereum.

Come funziona?

Guarda il nostro post su Testnet per una panoramica della tecnologia!

Perché la V2.0 è importante?

Due anni fa, abbiamo iniziato Connext con una semplice domanda:

“Come possiamo portare 1 miliardo di utenti a Ethereum?”

Questa domanda ci ha portato attraverso un sacco di iterazioni di prodotto alla confluenza di scalabilità, UX e trasferimenti Ethereum. Abbiamo ipotizzato che gli utenti finali vogliono un’esperienza senza soluzione di continuità e coerente nei loro portafogli e applicazioni, indipendentemente dal fatto che abbiano Eth per il gas, o quanto sia congestionata la blockchain, o anche su quale sidechain/plasmachain/shard siano.

Sapevamo di aver colpito qualcosa di importante quando abbiamo spedito la Dai Card v1 all’inizio di quest’anno e abbiamo visto reazioni come questa:

Nella costruzione della v2.0, i nostri obiettivi erano semplici. Primo: raddoppiare ciò che gli utenti già amano di Connext. Questo significava semplificare ulteriormente le integrazioni di Connext, reimplementare un facile onboarding tramite link come impostazione predefinita, e – cosa più importante – continuare a lavorare per rendere i nostri già magici trasferimenti ancora più veloci.

Secondo: ri-architetturare Connext come una rete principalmente da portafoglio a portafoglio, che le dApp possono poi agganciare per i loro specifici casi d’uso. Abbiamo scoperto che i portafogli hanno amato l’esperienza utente abilitata dalla v1, e così abbiamo ridisegnato il client Connext per lavorare molto più facilmente con i paradigmi di sviluppo dei portafogli esistenti per la gestione delle chiavi e lo stoccaggio.

Terzo: ripensare il nostro approccio ai punti più dolenti degli utenti. Nella v1, la parte più difficile di Connext era, senza sorpresa, il processo di depositare e ritirare dal canale onchain. Nella v2.0, non solo abbiamo semplificato il deposito/prelievo, ma abbiamo anche reso molto possibile per i portafogli di iniettare un fornitore per il canale di un utente in una dApp, rimuovendo la necessità per gli utenti di depositare in più di un canale per cominciare. Un altro enorme mal di testa nella v1 era l’inflessibilità del protocollo, il che significa che ci volevano settimane o mesi per reagire al feedback degli utenti. Nella v2.0, possiamo invece aggiungere il supporto per nuove applicazioni o caratteristiche in pochi giorni.

Quarto: fare progressi credibili e significativi per diventare un sistema più decentralizzato e con meno fiducia. Mentre la vera decentralizzazione è ancora un po’ lontana, siamo passati con successo ad essere completamente non-custodiali e abbiamo posto le basi per implementare il multihop in stile Lightning senza troppi cambiamenti futuri al protocollo. Copriamo questo in modo più dettagliato in Trust Assumptions qui sotto.

v2.0 di Connext è il culmine di tutto il fantastico feedback che abbiamo ricevuto finora dalla comunità, ed è anche il primo passo verso un Ethereum layer due che è pronto per l’uso quotidiano.

Grazie a tutti voi per aver fatto parte del nostro meraviglioso viaggio finora!

Ipotesi di fiducia

Quando abbiamo lanciato la Dai Card sulla v1 di Connext, abbiamo elencato le principali ipotesi di fiducia della nostra rete. Questa volta, rivedremo i nostri vecchi presupposti oltre a coprire i nuovi introdotti in questo aggiornamento.

Mentre in volo, alcuni pagamenti erano custodial

Nella v1, i fondi degli utenti erano sempre non custodial ma i trasferimenti stessi, mentre erano in volo, erano a volte tenuti dall’hub. Questo era particolarmente vero per i trasferimenti più condizionali come i pagamenti Link o i trasferimenti a destinatari offline.

Nella v2.0, tutti i trasferimenti sono completamente non custodiali, anche quando sono in volo. L’hub non ha la possibilità di rubare i tuoi fondi. Questo è possibile perché la v2.0 supporta nativamente gli aggiornamenti generalizzati dello stato nei canali, dando loro molta più flessibilità.

L’hub teneva la copia “master” dello stato e i client non facevano il backup dello stato per default

Nella v1, se si andava offline, l’hub era l’unica entità che persisteva il tuo stato. Questo era ottimo per la compatibilità tra dispositivi, ma significava che ci si affidava all’hub per ripristinare il proprio stato con precisione e per essere sinceri durante le dispute. Inizialmente volevamo risolvere questo problema facendo il backup dello stato su IPFS, ma da allora abbiamo deciso di andare in una direzione diversa.

Nella v2.0, la memorizzazione e il backup dello stato sono lasciati al portafoglio. L’utente deve avere una copia locale dello stato per eseguire un canale, che agisce come una persistente “copia di lavoro” dello stato, ma i portafogli possono e probabilmente dovrebbero creare ulteriori backup remoti. I client non recuperano più lo stato dall’hub per default, anche se possono opzionalmente farlo se l’utente finale lo sceglie. Inoltre non richiediamo più che le controversie sui canali siano risolte solo dal proprietario del canale – questo rende possibile ai fornitori di portafogli di agire come torri di guardia per i loro utenti.

Gli aggiornamenti avvengono via http e sono censurabili

Nella v1, l’hub era un server REST e i client comunicavano gli aggiornamenti tramite POST http. Questa era una buona tattica per mantenere le cose semplici, ma significava che l’hub imponeva un flusso goffo basato sulla richiesta per aggiornare gli stati e poteva censurare quegli aggiornamenti.

Nella v2.0, siamo passati a NATS – un sistema di messaggistica p2p altamente scalabile, leggero e open source. NATS ci permette di spostare l’hub dal paradigma http-request, rendendo possibile avere più copie indipendenti dello stato. Sfortunatamente, richiede ancora l’implementazione di un server di messaggistica (attualmente ospitato dall’hub) per funzionare correttamente. Questo significa che mentre ora sono p2p, i messaggi nell’hub centralizzato v2.0 sono ancora censurabili come nella v1.

La decisione di usare NATS in modo specifico è un passo verso la soluzione di questo problema, però. NATS supporta la messaggistica decentralizzata (mesh) mettendo in cluster molti server di messaggistica insieme. Questo significa che possiamo spedire istanze NATS in cluster come parte dei nodi Connext nella nostra eventuale rete decentralizzata, per decentralizzare il nostro strato di messaggistica in tandem.

I trasferimenti avvengono attraverso l’hub e sono censurabili

Nella v1, ogni utente depositava in canali con l’hub e poi indirizzava i trasferimenti l’un l’altro attraverso l’hub (simile a come lavorano i relayers 0x). Questa era una tecnica di bootstrapping per creare un sistema affidabile e facilmente iterabile mentre raccoglievamo dati sugli utenti e testavamo una varietà di casi d’uso diversi. Questo significava anche, tuttavia, che il nostro hub poteva essere censurato, DDoS o chiuso, mettendo il nostro servizio di pagamento offline (anche se nessun fondo degli utenti sarebbe stato perso!).

Al lancio, la v2.0 usa lo stesso paradigma e può ancora essere censurata. C’è ancora del lavoro da fare prima di poter essere una rete veramente decentralizzata. Tuttavia, l’aggiunta della messaggistica p2p e dello stato generalizzato è un enorme passo nella giusta direzione. Possiamo ora iterare rapidamente su protocolli di trasferimento più estensibili senza dover riscrivere completamente il sistema o aggiornare drasticamente le interfacce.

Client proxy attraverso l’interfaccia dell’hub per accedere a Redlock

Decentrando la memorizzazione dello stato dell’utente, abbiamo introdotto la complessità relativa all’aggiornamento concorrente dello stato. Nei server centralizzati, la concorrenza è gestita bloccando/sbloccando lo stato ad ogni operazione. Per il nostro paradigma distribuito, abbiamo integrato le chiusure distribuite di Redis nell’hub. Sfortunatamente, Redis non è supportato nativamente nei browser e Webdis, l’interfaccia Redis basata su browser, non supporta Redlock.

Nell’interesse di una spedizione efficiente, abbiamo costruito un’interfaccia proxy ospitata dall’hub per il client per bloccare/sbloccare il proprio stato. Nel breve o medio termine, ci aspettiamo di reimplementare o modificare Webdis per usare anche il locking distribuito.

Dettagli tecnici

I contratti sono stati controllati indipendentemente:

• Provide Audit Report
• Decenter Audit Report

Contratti della rete principale:

• 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

Codice contratto:

• Contratti di protocollo di finanziamento controfattuale
• Contratti di aggiudicazione controfattuale