What’s Next for Connext?
Introducing the Connext Network
The Story So Far
Layne, Rahul, and I started working on Connext almost a year ago today. Although we had a naive understanding of the ecosystem, we were bound by the shared intuition that a decentralized future could be one that is intrinsically more egalitarian. This is why, from day one, our goal was to find a way to bring blockchain technology to the mainstream market.
At the time, we believed this to be a problem rooted in the accessibility of dApps — that adoption was the main barrier to the decentralized world. This was a belief rooted in assumptions which were formed prior to the ICO mania and mainstream attention that followed. Through a long process of learning and growth, however, we discovered that there is far more critical infrastructure that needs to be implemented before widespread blockchain adoption can be possible.
In other words, while our goal and vision remain the same, we have realized that the problem that we need to solve is different from the one we had originally imagined.
Our Vision of the Future
We think the ideal future is a tokenized world that anyone can participate in.
We envision that, in this world, most major functions that involve value will be secured by blockchains including existing Web 2.0 applications, world financial processes, and eventually, governments. We also think that information asymmetry will no longer be able to be monetized — i.e. location services, payments, market data, financial primitives, social networks, etc. will all become public commodities in the form of protocols.
In an increasingly digitized world, this will mean millions, if not billions of transactions per second (tps) of data and value that will have to be secured by blockchain networks.
Why Aren’t We There Yet?
Aside from the work that needs to be done building these applications and protocols, there is still one major barrier that the ecosystem has yet to overcome: Ethereum can only process 20 transactions per second.
This problem isn’t a secret to anyone who pays attention to Ethereum development. However, the restrictions that this creates are often underappreciated. Let’s take one “killer” Web 2.0 application as an example: Uber does 1,000,000 rides per day. This means that, at minimum, they’re doing 11 transactions per second, roughly 50% of Ethereum network throughput and paying at least $100,000 per day at current gas prices.
At this point, discourse typically turns to Ethereum’s scaling solutions — a very fuzzy category of projects that all have deeply technical, fundamentally different mechanisms, and in reality, solve very different problems. The truth is, “scaling” for blockchains isn’t just one problem, but a set of interlinked problems. There is no silver bullet to bringing Ethereum to millions of tps. We will need a combination of different approaches to get there.
Perhaps more importantly, the accessibility of these solutions remains an open question. It’s unlikely that the future developers of decentralized marketplaces and high throughput exchanges will want to become experts in underlying protocol infrastructure. And yet, to use any of the scaling solutions that exist today, teams have to consult with or hire researchers who focus on these problems.
The closest exception to this is Loom Network’s Plasma implementations. They have done an excellent job of abstracting away the complexities of creating Plasma sidechains, so that developers can focus on actually building their dApp and getting users. While we think Plasma is awesome, we recognize that it is a mechanism most effective for handling n-party ecosystems (n>2).
So what‘s the best framework for 2-party interactions (payments, exchange, financial contracts, turn based games, etc.)? Through our research, we have found that state channels are the most efficient way to handle these.
The State of State Channels
Where are state channels now, though; are they living up to their promises of faster throughput and efficiency?
The ideas behind state channels have been around for years, and yet only two companies, SpankChain and FunFair, actually use them in production. Partly, this comes from the fact that, in the past, a new channel had to be opened for each new pair of transactors. In terms of gas cost, this was only worth doing if the two transactors were going to interact >10 times with each other. Naturally, this limited state channels only to very few use-cases.
We can now solve this problem, elegantly, with our state channel hubs.
Mostly, however, the lack of state channel adoption is due to the problem we enumerated above: it is still too hard to deploy state channels in a production dApp. The vast majority of work that needs to be done has to happen through offchain protocols and there are no generally accepted frameworks for how to do this.
There are a lot of projects that are aiming to build state channel implementations and networks. “Full stack” implementations such as Raiden, Liquidity.Network, Celer, L4, and then research organizations such as Perun, Finality, Magmo and many many others. However, there’s unfortunately very limited cooperation and cross communication between these projects, and even less communication with the developers in the space who are working to solve real problems.
It is likely that different implementations and approaches will be optimal for different use cases. Payments, just by itself, is a multi-trillion dollar industry and “state” would be even larger. We don’t believe in the idea that there will be one master state channel framework which will be used for everything, but rather a number of different networks that will interoperate.
In the same way that Loom has made Plasma approachable, we hope to make state channels easy to implement for every project. We aim to do this by collaborating closely with both existing applications and other approaches to scaling, to create one seamless developer experience. We will know we have succeeded when a new Ethereum developer with no knowledge of underlying protocol infrastructure can create a dApp that scales to millions of concurrent users.
What Do We Become?
Today, Connext is an open source platform for easily setting up state channel hubs. With Connext, Ethereum projects can enable low cost, near-instant transactions for their users.
Users of projects that set up a Connext Hub can open state channels with the Hub and transact with any other user that is also connected to the Hub without paying gas or needing to wait for block confirmation time. The throughput of these transactions is only limited by the bandwidth of the Hub.
This means that, with Connext, an Uber-size p2p application is feasible on Ethereum today.
Soon, Connext will allow companies to scale more than just their transactions, but allow for instant exchange and other higher-order 2 party interactions as well. We will also eventually connect all of the hubs in our ecosystem (and in the ecosystems of other state channel networks) into the Connext Network, further reducing the need for participants to open and close channels.
This will mean that one day, a user of a payments company that is a Connext Hub, will be able to initiate an interaction with a user of an exchange that is a node in Bitcoin’s Lightning Network, play a fully trustless game of chess between them, and be paid out a prize in ETH or BTC all without ever needing to pay transaction fees.
We also expect that, over time, we will iteratively reduce our involvement with the Network, moving towards an open governance model.
Our ultimate goal is for Connext to become an open, developer-friendly, fully community-governed, network for trustlessly handling two-party interactions of any sort, which is used as the underlying infrastructure for trillions of dollars worth of transactions.
We’d like to thank all of our wonderful investors, advisors and supporters for their help with our journey. We’re excited to continue to learn and build with the community.
If you’d like to know more about Connext, you can:
- Check out our repositories (documentation coming this week)
- Tweet at us
- Email us at support@connext.network
- Check out our website
- Follow this medium account
