Connext

[hthillman]

dap: 4
project name: Connext Network
main site: https://connext.network
author: Hunter Hillman ([email protected], @hthillman)
discussions-to: N/A
status: Draft
created: 2018-09-13

Simple Summary

Connext is an open source network powering peer-to-peer microtransactions for the next generation of internet businesses.

Abstract

Connext's state channel hubs allow any user of a Connext Hub to trustlessly pay any other user of the Hub without needing to pay gas or wait for block confirmation. This enables a suite of use cases that were previously impractical to do in a trust-minimized way: high-frequency trading, IoT microtransactions, content micropayments, and streaming payments. In conjunction with other DeFi protocols, Connext Hubs will allow liquidity to trustlessly and cheaply flow among stakeholders.

Resources

• Site - https://connext.network
• Code - Github
• Developer documentation - https://docs.connext.network/

Motivation

Connext enables cheap off-chain peer-to-peer micropayments, with near-zero latency. Several of the projects in DeFi aim to unlock massive amounts of liquidity; Connext radically reduces the friction incurred by that liquidity. We aim to interoperate with the various DeFi protocols to enable better and more powerful second-order projects.

Instant finality and gas-free transactions carry obvious UX benefits, but they also enable new transaction patterns. Like 0x, Dharma and others, we see Connext as underlying, trust minimized open source infrastructure. It is meant to be used by off-chain projects (relayers) who can combine it with other, similar, protocols to make entirely new types of businesses:

• An integration with a DEX built on 0x or some other exchange protocol could allow high-frequency/algorithmic trading of tokenized securities, debt, and other assets. Transactions would be cleared through a Connext Hub and the DEX would remain non-custodial.
• An integration with a Dharma relayer could allow for fascinating use cases around one to many or many to one microlending. Could be used borrow against small amounts of locked up capital in plasma chains, for instance.
• Contributors are currently discussing on building recurring payment infrastructure on top of Connext. This would enable p2p streaming payments or subscription payments which could be used by any centralized (relayer) business that sets up a Connext Hub.
• A business built on top of Set Protocol could use Connext to create a service that allow faster/cheaper rebalancing of assets within Set bundles.

Connext also plans to iteratively enable more complex state transitions in our state channel framework, which will continue to open up new potential use cases.

Specification

How it works: Launch Post and Explainer

Deeper Background: Eric Olszewski's deep dive into our system

Even deeper background: A recent dev update on how our specification has evolved

UX example: The first Connext Hub is being used to enable content microtipping on Spank.LIVE

Rationale

We approached our design decisions with an eye towards developer and user experience, which meant creating a minimal, modular, and extensible system.

Connext's state channel framework is based on Perun's specification of "virtual channel" hubs. We chose virtual channels, or "threads", over a hashlock-based system for several reasons:

• First, threads remove the need for an intermediary processor to observe every transaction between two parties.
• Second, we found that threads are much easier to upgrade to varied forms of generalized state than hashlocks. This aligned with our interest in creating a system that could evolve with its users.
• Third, we found that threads are computationally cheaper for repeating payments than hashlocks because they do not incur the computational cost of resolving a hashlock each time a payment is made. This means that, because they rely on more robust routing mechanisms, hashlock-based systems may be better for one-off payments (think retail). But for micropayments, high-frequency payments, and other payments pertinent to finance, threads are unmatched.

However, our implementation does diverge from Perun's specification. In their framework, virtual channels are ephemeral and are beholden to a time limit. This is because their hub is allowed to "drop out" of an thread when two parties begin to exchange state updates and return later to help facilitate payments and close the thread. We realized that this was particularly burdensome from a UX perspective; closing a thread after a specified amount of time would result in high availability requirements for end users. Instead of enforcing a time limit, we have each party in the thread (and the hub) record the Merkle root of the initial thread state. When the parties choose to close a thread, the hub does a Merkel proof to ensure that the thread was not already closed and confirms that the balances make sense prior to facilitating the transaction. This mitigates the availability requirements on users and allows threads to persist for as long as the Hub is willing to keep collateral parked.

Because Hubs (much like nodes in Lightning Network) require 1:1 collateralization of funds in open state channels, the system remains trustless. Moreover, the Hub does not actually take custody of user funds at any point; in conjunction with a comprehensive dispute resolution process, this ensures that all Connext threads and channels retain the security of the underlying blockchain.