Overview
One of the most important themes in the software architecture of Kchannels is the centralization of risk. To achieve good UX--the fundamental value proposition of Kchannels--the system consciously and deliberately attempts to absorb risk from its users, and the effects of this seemingly unusual (in the blockchain space) design choice ripple throughout the architecture, including both the channel and transaction constructs, as well as security and scaling.
Centralization of risk implies a centralized system, and in a sense that is indeed the case. However, Kchannels is anchored in Ethereum's Mainnet, and carefully balances the pros and cons of Layer2 centralization against the pros and cons of the underlying decentralized blockchain. The result is a nimble system that can open up new use-cases in the blockchain ecosystem.
The original payment channel paper described a two-party payment channel, where trust was ensured by each party watching the blockchain for the other's settlement request. This works well, but does not scale; for an N-party channel, one requires all N parties to be in consent with each other before a channel is considered settled and anyone can get their funds out. A hub-and-spoke architecture for a payment channel aims to address that, but now the hub has a few new problems: it has to keep track of all its smart contracts, it has to stake its own funds to each and every one of them, and it has to periodically rebalance those smart contracts to ensure the continued operation of those channels. This once again limits how fast and how far a payment channel can scale. There have been multiple creative ideas proposed to help with these new problems, including creating a payment channel mesh network, but so far none of these ideas have been able to address them sufficiently to produce a mainstream system based on a payment channel that can scale up and down freely.
Kchannels' approach is to take a step back and look at the original problem--that of risk. We noticed that by drawing all the risk everywhere into one central location, it becomes much easier to manage it. This opens the door to virtually unlimited scaling of the resulting system, without any of the added burdens mentioned above. The many benefits of this decision are listed throughout the documentation. The downside? Anything that centralizes risk also centralizes other aspects of the architecture, such as ownership of key elements.
Kchannels gathers all the risk from all its channels into something called a deployment, which charges modest transaction fees to manage that risk for everyone. Needless to say, all actors within a deployment have to be owned by a single party. With Kchannels bound by its smart contract to behave a certain way, any transaction obeying the rules of the system can be trusted, even if the end-parties on the transaction do not trust each other. With risk now out of the way, there are new possibilities in the realm of UX, including suitability for commerce.
A benefit of having a deployment defined so rigidly is that all boundaries between Kchannels and the rest of the world are well demarcated in the Kchannels API. We are now free to decide how transactions are performed underneath those APIs based on the best practices of the day; for example, today zones find and talk directly to each other over a private network, resulting in a very flat internal network topology, but as the system grows that may need to change. Users will never need to know or care about any changes to how things are done, resulting in a "it just works" user experience.
A channel is an established relationship between a zone and a user. By virtue of having such a relationship with a zone, a user is able to interact with any other user at any zone within Kchannels, as well as with every Ethereum address on the blockchain. We sometimes refer to this concept as a multichannel to distinguish it from the more traditional channel design.
A Kchannels channel is defined by a channel definition document, which governs how transaction are going to be performed under that channel, as well as who is allowed to sign for them. Our channels are thus quite customizable to fit everyone's needs.
It is important to note that a user only interacts with their assigned zone and the zone manager, the latter of which is used to create and modify channel definitions.
Kchannels has a notion of transactions that is distinct from blockchain/Mainnet transactions. A transaction takes place between two open channels (the sender's channel and the recipient's channel) that briefly "come together" for the purpose of the transaction. Each of these channels has its own definition for a valid transaction, which only governs their side of the transaction. The resulting object is only valid if it fulfills the requirements of both channels' channel definitions.
Transactions can only be initiated by a valid sender at the sender channel and terminated by the validator identity of the recipient channel. Ideally the sender and recipient zones would be merely facilitators, though in Light Mode this is relaxed somewhat by enabling the recipient zone to act as a validator for the recipient.
Kchannels also supports external transactions, which are transaction between an open channel and the blockchain. This works in both direction, and one side of the in-channel transaction is the smart contract identity listed as a "zone". In this case a blockchain transaction replaces the requirement for a zone signature and user signature, as the blockchain transaction linked is a matter of public record (the blockchain) and its validity can be easily verified.
Transactions can transfer one or more different assets. This is also true for external transaction, in which case a single in-channel transaction results in a single transaction going into the smart contract, and then multiple internal transactions out of the smart contract.
Transactions are charged a small transaction fee (which could be 0) as specified in the channel definition. Transactions going on-chain are charged gas fees (which definitely won't be 0).
A channel with Kchannels is quite customizable, with the user being able to set various parameters, such as who is responsible to sign off on an incoming transaction, who is responsible to sign off on an outgoing one, who is the owner of all assets within, etc. One such setting is the "mode" of a channel, which has a big impact on the resulting user experience and how much control a user has over what is happening.
Normally, Kchannels is simply a facilitator of transactions; nothing in Kchannels initiates or terminates transactions. However, this is not always the most convenient user experience, or even the most desirable. For the sake of convenience we give the user the choice how they want to run their channel:
- In Light Mode, the user is responsible for initiating (sending) transactions, but he does not want to be involved in receiving them. He doesn't even need to be online! In this case Kchannels becomes just a single JSON-RPC API, which he drives from a mobile app, web page, or any other client. This is the simplest, most convenient user experience possible. There are some potentially important implications to this.
- In Watchtower Mode, the user wants ultimate control over his assets; any transaction coming in or going out must be signed off by an authorized agent, either directly (by getting prompted for a signature) or indirectly (by virtue of signing a blockchain transaction). Once again there are important implications, particularly when it comes to running dedicated and always available infrastructure.
Kchannels aims to serve a great many users. Whereas other implementations appear to create payment channels for individual merchants or individuals transacting directly, Kchannels is going for a much larger scale.
Although Kchannels deployment could be created for individuals or individual merchants, the real beauty and power of Kchannels is its ability to scale to the payment channel equivalent of a "payment network": a place where any number of individuals and unrelated businesses exchange payments. Kchannels can scale simply by adding additional hardware on the fly, and a big part of that is being very modular; we have zones as domains of control, and we can add more right into a production deployment as the need arises.
Dispute resolution is what makes Kchannels non-custodial and trust-minimized. The Kchannels dispute resolution mechanism is quite a bit more elaborate than that of other systems. It aims to do all of the following:
- enforce the most current active version of a channel definition - A channel definition is something that will change over time, with the user negotiating new versions of it as his needs and circumstances change. There is always at most one active channel definition for each channel and only that channel definition can be disputed.
- enforce the most recent state of the channel - Every time there is a disagreement between the most current channel state (the list of assets present and their balances), this part of the dispute resolution will make a binding decision on both parties as to what the proper channel state should be.
- enforce the prompt handling of blockchain transactions within the system - Kchannels transactions can result from blockchain transactions, just as they can result in blockchain transactions being created themselves. Every time this doesn't happen within a reasonable period of time, this part of the process can restore the impacted assets back to the affected user, either by updating his channel state, or by transferring the assets back on-chain.
- allow the option to close a channel on-chain and return all assets - once a dispute has established the most current channel definition and the most current channel state, it can force a channel to close by transferring all the user's assets back to him. This is a measure of last resort, but it is always available to all users, whether or not they are in disagreement with their zone. Of course, asking the zone to do it is slightly cheaper as making decisions on-chain requires gas.
The security of Kchannels is a big topic. We try to secure many parts of our system, such as our users' channels, their transaction history, their balances. To protect the integrity of the system we have multiple layers of security measures both in place and planned for the future. The dispute resolution feature described above is just one example.
Last modified 2yr ago