Connext v2.0 está na Mainnet

tl;dr: Nós enviamos a coisa! 🚢

v2.0 é fantástico porque: dobra o que as pessoas adoram da v1, suporta nativamente carteiras, alivia os pontos de dor da v1 e melhora as suposições de confiança.

Wallets e dApps podem começar seguindo o Quick Start nos nossos documentos. Um work-in-progress (Rinkeby) Dai Card está disponível aqui.

Após dois longos meses de testes, auditorias e correção de bugs de Rinkeby, nós implantamos a v2.0 do Connext! 🌟

• O melhor lugar para entrar é o guia de Início Rápido em nossos documentos.
• Venha conversar conosco em nossa discórdia se você tiver alguma dúvida.
• Código está disponível em: https://github.com/ConnextProject/indra
• Trabalho em curso Rinkeby v2.0 Dai Card está disponível em:: https://rinkeby.indra.connext.network

E uma Dai Card Mainnet v2.0? Em breve! Estamos trabalhando para garantir que não haja gotchas UI que possam causar perda de fundos para os usuários.

V2.0 roda em Counterfactual. Quando você integrar a v2.0, você também irá eventualmente suportar o framework State Channels – o padrão unificado para canais no Ethereum.

Como Funciona?

Cheque o nosso post de teste para uma visão geral da tecnologia!

Por que a V2.0 é importante?

Dois anos atrás, começamos o Connext com uma simples pergunta:

“Como podemos trazer 1 bilhão de usuários ao Ethereum?”

Esta pergunta nos levou através de muitas iterações de produtos no conflito de escalabilidade, transferências UX e Ethereum. Nós colocamos a hipótese de que os usuários finais querem uma experiência contínua e consistente em suas carteiras e aplicações, independentemente de terem Eth para gás, ou o quão congestionada está a cadeia de bloqueio, ou mesmo em que sidechain/plasmachain/shard eles estão.

Sabíamos que tínhamos atingido algo importante quando enviamos o Cartão Dai v1 no início deste ano e vimos reacções como esta:

Quando construímos a v2.0, os nossos objectivos eram simples. Primeiro: dobrar sobre o que os usuários já adoram no Connext. Isto significou simplificar ainda mais as integrações do Connext, reimplementar o fácil onboarding via links como padrão, e – o mais importante – continuar a trabalhar para tornar nossas já mágicas transferências ainda mais rápidas.

Segundo: rearquitetar o Connext como uma rede primariamente wallet-to-wallet, na qual os dApps podem então se conectar para seus casos de uso específicos. Descobrimos que as carteiras adoravam a experiência do usuário v1 habilitada, e por isso redesenhamos o cliente Connext para trabalhar muito mais perfeitamente com os paradigmas existentes de desenvolvimento de carteiras para gerenciamento e armazenamento de chaves.

Terceiro: repensar nossa abordagem para os maiores pontos de dor dos usuários. Na v1, a parte mais difícil do Connext foi, sem surpresas, o processo de depositar e retirar do canal onchain. Na v2.0, não só simplificamos o depósito/retirada, mas também tornamos muito possível que as carteiras injetassem um provedor para o canal de um usuário em um dApp , eliminando a necessidade de os usuários depositarem em mais de um canal para começar. Outra grande dor de cabeça na v1 foi a inflexibilidade do protocolo, o que significa que levou semanas ou meses para reagir ao feedback do usuário. Na v2.0, podemos adicionar suporte para novas aplicações ou funcionalidades em dias.

Fourth: fazer progressos credíveis e significativos para se tornar um sistema mais confiável e descentralizado. Enquanto a verdadeira descentralização ainda está um pouco distante, nós nos movemos com sucesso para ser totalmente não-custodial e lançamos as bases para implementar o multihop estilo Lightning- sem muitas mudanças futuras de protocolo. Cobrimos isso com mais detalhes em Suposições de Confiança abaixo.

v2.0 do Connext é o culminar de todo o incrível feedback que recebemos até agora da comunidade, e é também o primeiro passo em direção a uma camada dois de Ethereum que está pronta para uso no dia a dia.

Obrigado a todos por fazerem parte da nossa maravilhosa jornada até agora!

Pressupostos de confiança

Quando lançamos o Cartão Dai na v1 da Connext, listamos os principais pressupostos de confiança da nossa rede. Desta vez, vamos rever nossas antigas suposições, além de cobrir as novas suposições introduzidas nesta atualização.

Enquanto em vôo, alguns pagamentos foram custodiados

Na v1, os fundos do usuário sempre foram não-custodiados, mas as próprias transferências, enquanto em vôo, às vezes eram mantidas pelo hub. Isto foi particularmente verdade para transferências mais condicionais como pagamentos de Link ou transferências para destinatários offline.

Na v2.0, todas as transferências são totalmente não-custodial, mesmo quando a bordo. O hub não tem a capacidade de roubar seus fundos. Isto é possível porque a v2.0 suporta nativamente atualizações de estado generalizadas nos canais, dando-lhes muito mais flexibilidade.

Hub manteve a cópia “master” do estado e os clientes não fizeram backup do estado por padrão

Na v1, se você foi offline, o hub foi a única entidade que persistiu no seu estado. Isto era ótimo para compatibilidade entre dispositivos, mas significava que você confiava no hub para restaurar seu estado com precisão e para ser verdadeiro durante as disputas. Nós originalmente pretendemos resolver isso fazendo o backup do estado no IPFS, mas desde então decidimos ir em uma direção diferente.

Na v2.0, o armazenamento do estado e o backup é deixado para a carteira. O usuário deve ter uma cópia local do estado para executar um canal, que atua como uma “cópia de trabalho” persistente do estado, mas as carteiras podem e provavelmente devem criar mais backups remotos. Os clientes não recuperam mais o estado do hub por padrão, embora opcionalmente possam fazê-lo se o usuário final assim o desejar. Também já não exigimos que as disputas de canais sejam resolvidas apenas pelo dono do canal – isto torna possível que os provedores de wallets actuem como Watchtowers para os seus utilizadores.

As actualizações acontecem via http e são censuráveis

Na v1, o hub era um servidor REST e os clientes comunicavam as actualizações via http POSTs. Esta era uma boa tática para manter as coisas simples, mas significava que o hub mandava um fluxo baseado em requerimentos para atualizar estados e podia censurar essas atualizações.

Na v2.0, nós mudamos para NATS – um sistema de mensagens p2p altamente escalável, leve e de código aberto. NATS nos permite mover o hub para longe do paradigma http-request, tornando possível ter múltiplas cópias independentes do estado. Infelizmente, ainda requer que implementemos um servidor de mensagens (atualmente hospedado pelo hub) para funcionar corretamente. Isto significa que enquanto eles são agora p2p, mensagens no hub v2.0 centralizado ainda são censuráveis como na v1.

A decisão de usar NATS especificamente é um passo para resolver este problema, no entanto. NATS suporta mensagens descentralizadas (mesh) através do agrupamento de muitos servidores de mensagens em cluster. Isto significa que podemos enviar instâncias NATS em cluster como parte dos nós do Connext em nossa eventual rede descentralizada, para descentralizar nossa camada de mensagens em tandem.

As transferências acontecem através do hub e são censuráveis

Na v1, cada usuário deposita em canais com o hub e depois roteia as transferências entre si através do hub (similar a como funcionam os retransmissores 0x). Esta foi uma técnica de bootstrapping para criar um sistema confiável e facilmente iterável enquanto nós coletamos dados de usuários e testamos uma variedade de diferentes casos de uso. Isto também significava, contudo, que o nosso hub podia ser censurado, DDoS’d ou desligado, colocando o nosso serviço de pagamento offline (embora não se perdessem fundos de utilizador!).

No lançamento, a v2.0 usa o mesmo paradigma e ainda pode ser censurada. Ainda há trabalho que precisa ser feito antes de podermos ser uma rede verdadeiramente descentralizada. No entanto, a adição de mensagens p2p e estado generalizado é um enorme passo na direcção certa. Podemos agora iterar rapidamente em protocolos de transferência mais extensíveis sem a necessidade de fazer uma reescrita completa do sistema ou atualizar drasticamente as interfaces.

Proxies de clientes através da interface do hub para acessar o Redlock

Descentralizando o armazenamento do estado do usuário, introduzimos complexidade relacionada ao estado de atualização concomitante. Em servidores centralizados, a simultaneidade é tratada através do estado de bloqueio/desbloqueio em cada operação. Para o nosso paradigma distribuído, integramos os bloqueios distribuídos da Redis no hub. Infelizmente, Redis não é nativamente suportado em navegadores e Webdis, a interface Redis baseada em navegador, não suporta Redlock.

No interesse do envio eficiente, nós construímos uma interface proxy hospedada pelo hub para o cliente bloquear/desbloquear seu estado. No curto a médio prazo, esperamos reimplementar ou modificar Webdis para usar o bloqueio distribuído também.

Detalhes técnicos

Contratos foram auditados independentemente:

• Fornecer relatório de auditoria
• Decentrar relatório de auditoria

Contratos Mainnet:

• ChallengeRegistry.sol

>

• Transacção CondicionalDelegateTarget.sol
• CoinBalanceRefundApp.sol
• MultiAssetMultiPartyCoinTransferInterpreter.sol
• IdentidadeApp.sol
• MinimumViableMultisig.sol (singleton)
• ProxyFactory.sol
• SingleAssetTwoPartyCoinTransferInterpreter.sol
• TimeLockedPassThrough.sol
• TwoPartyFixedOutcomeInterpreter.sol
• TwoPartyFixedOutcomeFromVirtualAppInterpreter.sol

>

• SimpleTwoPartySwapApp.sol
• SimpleLinkedTransferApp.sol
• SimpleTransferApp.sol

>

Código do contrato:

>

>
• Contrafactual Contratos de protocolo de financiamento

>

• Contrafactual Contratos de ajuste

>