Technical overview
Kchannels is a type of payment channel solution, and payment channels are part of a wider ecosystem of Layer2 solutions that attempt to scale different properties of blockchains.
Transactions in a payment channel are usually performed off-chain, within the payment channel solution itself, but they are still enforceable on the underlying blockchain. The goal is to create a different user experience than the one of the underlying blockchain, while still creating transactions that are just as secure and final. There are many different architectures possible to accomplish this, though most focus on some combination of transaction throughput (number of transactions per unit of time), time to confirmation (time to confirm a single transaction), and privacy. In all cases those transactions are enforceable on the underlying blockchain. As the name indicates, payment channels handle payments, i.e. transactions that change ownership of Ether and/or ERC-20 tokens.
Payment channels provide three canonical features:
Fast transaction confirmation - no more waiting for blocks/confirmations as no mining is involved.
Low fees - much cheaper than Ethereum gas as no blockchain costs are involved.
Relative privacy - transactions are not visible on-chain in most cases.
At Kchannels we have come up with a very different architecture than other implementations. It focuses on user experience in order to enable commerce without any additional burdens. You are invited to read more about our reasons for building something so different in the next page. This section aims to introduce our architecture and the language that has evolved around it.
Kchannels works with a single smart contract, and all assets are pooled there. The smart contract does not keep track of who owns what, or even what channels are present in the system; it is merely there to hold on to the assets being handled by the system, as well as to provide essential services such as dispute resolution. It somewhat resembles a multi-signature wallet with some additional services added on top.
Components supporting the same smart contract are said to belong to the same deployment, and they recognize each other and trust each other by virtue of their respective component Ethereum identities being listed within the smart contract. It is important to note that all components belonging to the same deployment are owned by the same physical or legal entity, but each has a unique Ethereum identity.
The smart contract is monitored by components called zones. These are domains of control within the deployment. Each zone is responsible for a subset of users and their channels within the deployment. Zones act as facilitators for transactions and are not allowed to own anything within the deployment. In particular, they are never allowed to initiate (send) transactions on behalf of users, though they are sometimes allowed to terminate (receive) them, depending on the channel owner's own preferences.
Kchannels defines a channel as a relationship established with a zone. The channel isn't with anyone in particular (like a counterparty). Think of it as a standing contractual relationship between a user and a zone, like a cell phone connecting to a particular carrier. Any cell phone can call any other via their carrier.
A channel definition is the contract between a zone part of a deployment, and a user for the purposes of establishing a channel with the deployment. It contains a description of all signatories required for a transaction to be valid in both "sender" and "recipient" situations. It is a simple JSON structure, which must be signed by both the user (channel owner) and the zone in order to be considered in effect.
A transaction is a transfer of one or more assets from one user to another user. A transaction must always be initiated by a user and terminate at another user's channel. The sender and recipient channels may be part of the same or different zones. In the latter case the two zones internally work together to make sure they are on the same page regarding the transaction, and this is transparent to both users. In all situations a user talks only to the zone he has a channel definition with and the communication goes as follows: sender > sender zone > recipient zone (> recipient). There is no need for route discovery as all zones can directly interact with each other.
A transaction summary is a summary of how a transaction impacts a given transaction party's channel. A sender and recipient each have a different transaction summary as their channels are impacted differently: one is debited, the other is credited. A summary object is always required for a transaction to be considered completed, and it can be used to dispute a transaction. The purpose of this object is two-fold: first, we can now accommodate sophisticated transactions, without the need for the smart contract to interpret every aspect of them; and second, to act as a commit protocol on a transaction for the purpose of easy and consistent recovery from errors. Note that the sender (and in some cases the recipient) is required to complete a transaction, but a zone is allowed to fail any transaction it is a part of all by itself, but up to a point. When a transaction is in "Completed" state, it is final and may not subsequently fail or be "clawed back". In this case you will be able to see and validate the counterparty's transaction summary as well, as a proof of delivery for your transaction. Similarly, a "Failed" or "Fail Pending" transaction cannot subsequently result in assets changing ownership.
A zone manager is a component part of Kchannels used as an onboarding tool: it is used to facilitate channel creation and any channel updates requested by the user thereafter. Its job is to facilitate the process of creating and modifying a channel definition, as well as allocating those channels to zones. At present it also contains our simple user interface for the system, our user authentication mechanism, as well as some tools internally used for channel discovery. Eventually those will be moved out of there in favor of more decentralized solutions. Currently there can be only a single zone manager, but eventually this limitation will be lifted.
We distinguish between two types of transactions: in-channel transactions (or simply transactions) are transactions between two parties with open channels. These transactions pay transaction fees and happen almost instantly. The recipient is able to operate on the funds they just received instantly, which includes withdrawing them back to the underlying blockchain. External transactions are between a party with a channel and party on the blockchain. External transactions pay a gas fee as their transaction fee, which will vary based on the current gas price. Examples of external transactions are:
a user withdrawing their funds back to their wallet on the underlying blockchain. In this case the sender zone works with the smart contract to initiate a blockchain transaction out of the smart contract and into the user's Layer1 wallet. This is done for the time it takes to mine a transaction - no "dispute periods" involved. Normal gas fees apply.
a user transacting with someone who does not have a channel at the deployment - in this case their funds are sent on the underlying blockchain, turning Kchannels into a simple wallet for the sending user. Once again, gas fees apply.
a user depositing assets into their own channel by performing a blockchain transaction to the Kchannels' smart contract. In this case their zone will note the incoming blockchain transaction and credit it to their channel, usually within seconds of the transaction being posted into a block. In this case no additional fees apply as the user is already paying for gas.
In all of the above cases it is up to the zones to deal with the "fuzziness" of the blockchain and present a very deterministic user experience.
A dispute is a situation where a user is not in agreement with their zone on the most current state of their channel. This situation results in that user being temporarily unable to send or receive transactions on it while their proper channel state is being determined. Unlike other implementations, a dispute is always between a user and their zone, a strictly local condition, with the rest of the system being able to operate as normal. Also unlike other systems only the user is able to initiate disputes, not the zones, and to their own channel only. The implication of this are important:
If a transaction between a sender and a recipient is successfully disputed by sender, the sender channel is restored to the pre-transaction state, but the recipient gets to keep what they got. The balance remains at the expense of the deployment as it has signed and is being held liable for an invalid transaction: there is no "clawback" of completed transactions.
The only party able to dispute a channel is its owner, which in turn means without the owner, or someone they have authorized, disputing or transacting, all assets within their channel are completely safe and frozen in place. There is no need for a user to watch the blockchain anymore.
Dispute resolution happens via the smart contract, and at the end of that the user is allowed to close their channel and withdraw all their assets directly from the smart contract, completely bypassing the Kchannels backend.