Channels
A channel represents a user's standing relationship with a zone at a Kchannels deployment. It is not a relationship with a transaction counterparty.
Channels are flexible, secure, and full-featured--so that most users will only ever need to create a single channel, ever. In all cases channels are easy to open and close, and can be quickly created and destroyed as needed, all at no cost to the user.
A channel definition (CD) describes what it takes for a transaction to be valid for a given transaction party (user). To open a channel means that the user and the backend agree on a CD. The CD specifies several fields.
Firstly, the CD defines the owner of the channel. The owner has the authority to open, renegotiate, or close the channel, and he ultimately controls all assets within the channel. Importantly, the owner's address is the identity used to discover the channel. An owner is also allowed to initiate disputes of his channel with the smart contract.
The CD also contains a list of approved senders. These are addresses that can initiate (send) transactions from the channel on behalf of the owner. The list of senders could be used to allow several of the user's devices (phone, laptop, etc.) to use the channel without needing to share the owner key. Senders have full access to the entire channel balance, but they cannot modify the channel. By definition, the channel owner is also a valid sender. It is possible to have multiple channels with sender identities in common, or even an owner of one channel being a sender on another.
The CD specifies the zone to which it is assigned, since a channel always lives at a zone. A Kchannels deployment is separated into zones of control in order to increase its availability and resiliency, as well as to help mitigate risk. The zone to which a channel is assigned is responsible for policing that channel, and its signature is required on any and all transactions into or out of the channel. A single zone can be responsible for many channels owned by many different owners.
The CD also lists a validator address. This is the identity that has to sign off on any transaction received into the channel. In Watchtower Mode, the validator address is the address of the watchtower. In Light Mode, the validator address is set to the zone address, allowing the zone to receive incoming transfers on behalf of the user. The watchtower is also allowed to initiate a dispute on the channel with the smart contract, as it maintains an independent copy of the entire channel history and can spot discrepancies as they happen. For more information, see Modes.
Finally, the CD specifics the rating ID, which describes the fee structure (if any) for transacting with the channel. This parameter allows for flexibility around transaction fees; for example, some channels may be billed on a "per use" fashion, while others can be charged commission, while yet others are billed a flat monthly fee. In some circumstances, it is even possible for a recipient to cover the sender's fees (e.g. a merchant covering its customer's fees). Fees are intended to be competitive with Mainnet gas fees, legacy financial system fees, and even the fees of other Layer2 solutions.
Channels can hold multiple assets (e.g. ether and several ERC-20 tokens).
A user can easily add assets to and withdraw assets from an open channel, all in the time it takes to mine a transaction on the blockchain.
A user can safely walk away from an open channel without withdrawing, and there is no risk of losing funds while he is not paying attention. Only the user can dispute or transact with his assets.
When a user wants to open a channel, they requests a draft channel definition from the Zone Manager. The Zone Manager, responsible for onboarding and managing channels, selects a zone to which the channel will be assigned, and it returns an unsigned CD with some fields pre-filled for convenience (including the zone address). The user is free to modify some of these fields (senders, validator address). When he is happy with the CD, he signs it and gives it to the backend. Both the zone and the zone manager also sign the CD and return the triply signed CD to the user. The channel is now open and the CD is binding on all parties--in effect, a valid contract.
Channels are versioned and can be modified by their owner: the version number is increased, but the channel ID stays the same. The most common reason to do this would be to modify the list of senders. The owner can also switch the channel from Light Mode to Watchtower Mode and vice versa by updating the validator address. To modify the channel, the process is much the same as above, with the three signatures once required and applied to the resulting CD. At that point the old version becomes retired and can no longer be used. It is important to note that no transaction from a previous version of a channel definition can be disputed.
Channels can be closed (assuming they have a 0 balance for all their assets), at which point they become unusable forever. But most of the time there is no reason to close a channel.
Ultimately, channels are designed to be long-lived relationships, which is where their real power and benefits come from. This is particularly useful in a commercial context.
A transaction is an interaction between two open channels--the sender's channel and the recipient's channel. Therefore, a Kchannels transaction is a "coming together" of two open channels for the purpose of transferring assets. During the course of a transaction, both channels are temporarily locked and cannot transact with any other channel. Once the transaction completes, they are again free to transact with others. There are, of course, strict limits on how long a transaction can occupy a channel, and these are enforced by the corresponding zones.
This one-transaction-at-a-time limitation is important because during a transaction the channel balances are updated and this cannot be a deterministic process if transactions can write over each other's state changes. Most users will not find this to be a problem; merchants, however, might need the ability to handle multiple concurrent transactions when dealing with their clients. To accommodate this we plan to offer the ability to open multiple channels.
Last modified 2yr ago