Scaling

The Kchannels architecture is designed for considerable scale, on the order of thousands of transactions per second.

Background

The original paper for payment channels only describes a 2-party payment channel, which enables two people to interact off-chain, while keeping their transactions enforceable on-chain. The problem is that this architecture, although brilliant, does not scale with the number of parties; an N-party channel with the same smart contract requires all N participants to be in consensus for any of them to be able to settle the channel and withdraw their funds. Furthermore all N participants would want to enter, and then settle, the channel at the same time, and still need to monitor the smart contract for fraudulent settlement requests from all other participants. Clearly this architecture needs some help in this regard.

Enter hub-and-spoke solutions. Such solutions always try to "assemble" multiple 2-party payment channels as above, each with its own smart contract, around a central hub, so any one user can talk to any other user. This is usually combined with some sort of solution that ensures the hub cannot simply embezzle all the assets and not pass them on. There are a number of these solutions out there today, in various states of maturity. An architecture like this has some clear benefits:

• it can scale quite a bit

• users don't all need to enter or exit at the same time

• a dispute is always between a user and the hub--a localized situation

It also has some problems:

• The hub has to "stake" some of its own funds in each and every smart contract it manages, putting some significant limits on how far and how fast it can grow its active users. There is now pressure on users to finish using their payment channels, settle them, and exit, so the hub can reclaim its staked funds for use by other users.

• The hub has to constantly shuffle assets between its various smart contracts to keep channels that predominantly send funds and channels which predominantly receive funds functional. This disparity in how channels are used causes one side of the 2-party channels to run out of funds to transact with. The shuffling of assets happens through on-chain transactions, which cost gas and sometimes limit the availability of the users' channels.

• Lastly, all 2-party channels around the hub are limited in the assets they can transact with. This is usually an ERC-20, sometimes a custom one, that all users have to exchange their assets to before they can even enter into the channel. While this process can be usually automated, the associated gas fees are unavoidable, and it is still impossible to transact in something other than the one approved asset.

All these tend to limit the usability of hub-and-spoke payment channels to individual merchants, or a small group of merchants connected in some way, who are quickly going to realize that the vast majority of the traffic flows from their customers to them, and not between customers. With that observation, there emerges the pressure to lower the cost of running the hub-and-spoke architecture by limiting how much the hub stakes into the individual 2-party channels, resulting in the entire payment channel turning permanently into a redeemable in-store credit solution, not the anyone-to-anyone payment channel originally envisioned.

Mesh solutions are very attractive as they try to assemble multiple 2-party channels into a mesh of some sort, so there is less of a danger for a few actors monopolizing the vast majority of transactions, and the end-users don't all have to have channels with each other in order for a transaction to make it across between any two users. In theory this is the perfect architecture, but current iterations of it shares a lot of the limitations of the hub-and-spoke solutions, with the added problem that now route discovery is a challenge. It also raises some new and fascinating problems such as:

• how individual users can choose which other users to create channels with in order to best facilitate their own use of the mesh as well as maximize their profit from others using their channels

• how much funds each of a user's channels needs to have staked in order to maximize the traffic through it, without "overstaking", which results in little to no additional benefit for the user

These questions are important as it benefits the mesh as a whole to always maintain its fully-connectedness with as many redundancies as possible. A perfect example of a mesh network with a lot of the same pressures is the Internet itself, which has over time centralized so that a handful of Tier 1 and Tier 2 networks act as a "hubs" to route the vast majority of the traffic worldwide.

The Kchannels approach

Kchannels attempts to address all this and more by employing only a single smart contract to pool all assets from all users, then merely deal with the titles to those assets. The only problem then is once again how to deal with users entering and exiting, as well as users doing so in bad faith. All of this is solved by centralizing risk into a single actor, the deployment, dedicated to this one purpose, who is now making sure everyone "behaves" and is collecting fees from all participants to do so. You can read about how we ensure this one actor does not itself misbehave in the Dispute resolution and Security sections.

With that out of the way, the only real issue remaining is the technical availability of the deployment, which now becomes a relatively straightforward infrastructure problem. Kchannels uses a divide-and-conquer solution to this problem; it divides the deployment into zones of control (i.e. zones), all of which are owned by a single party (so there can be no disputes for assets between them) and all managing a subset of the assets within the same smart contract. Then each zone needs to worry only about its own users and its own availability. This way adding additional capacity is a relatively straightforward process of beefing up individual zones (vertical scaling) at certain times, as well as adding new zones into the running deployment (horizontal scaling). Both of these are easily done by adding hardware as needed.

Our intention is to scale Kchannels beyond a private payment channel for a handful of merchants with their customers, and to a single payment network for all customers and all merchants to interact with each other. With the architecture described above, this is possible. With the clear APIs between ourselves and our users in place, we also have the freedom to evolve our architecture as we go, all while keeping our target user experience unchanged.