Zones
Zones are the workhorses of Kchannels: where all the magic happens.
A zone is a backend service that is responsible for a subset of the assets at the Kchannels smart contract. Recall that the smart contract does NOT track title (ownership) of the assets it holds--that is the responsibility of a zone. A zone also observes the blockchain, watching for smart contract events, and responds to them quickly and appropriately.
A zone also provides the primary API for the client and acts as his point of contact within Kchannels. A zone is where the client operates with their channel, including sending and receiving transactions. Zones facilitate transactions, and are never allowed to initiate them. It is always a user somewhere who does so, either by directly signing an object, or by performing an action on-chain. In some cases a user may choose to delegate the task to receive transactions, only receive, on their behalf in exchange for the additional freedom to not have to run always-available infrastructure to manage their channel (this is the case in Light Mode).
A typical transaction involves two zones: one facilitating the transaction on behalf of the sender, and the other on behalf of the recipient. It is possible for this to be the same zone, though this will not be the case in general. In the course of the transaction, the sending zone validates the transaction signed by the sending user, and if it is deemed valid (signatures are valid, assets are available, channel state and nonce check out), then it also signs the transaction. This vouches for the transaction before the recipient zone. Later, the recipient's zone also validates the transaction, making sure a trusted zone signature is present, and also signs it if valid. This vouches for the transaction before the recipient. In Light Mode, these three signatures (client's, sender zone's, and recipient zone's) are required for a transaction to complete. In Watchtower mode, the transaction also has to be validated and signed by an agent acting on behalf of the recipient, their watchtower, which is free to impose additional validity requirements on the transaction, such as it being part of a sale somewhere waiting for a payment.
Kchannels primary purpose is to encapsulate and manage the inherent risks of two parties, who do not necessarily trust each other, transact. The entire system is designed with this in mind, and the zones are the frontline workers doing so. When a zone signs a transactions, it makes a public statement that the transaction checks out and is valid. If at some point later this does not end up being the case, the Kchannels deployment is held liable for that transaction - not the sender, and not the recipient. Kchannels' architecture does not allow for clawback of completed transactions under any circumstances.
Each zone is only in charge of a subset of the assets at the smart contract as to avoid having a single component in charge of a large-valued assets. This is compartmentalization of risk: if a zone becomes compromised, it is only those assets that become unavailable to further transactions. The unavailable assets have to be withdrawn at the smart contract, thus closing the channels at the downed zone, at which point their owners are free to set up new channels with those assets.
To further manage risk situations, we are currently planning a feature to create ongoing reporting of how assets within Kchannels are being managed: at any point in time current and prospective users can check if our deployment is "in balance". You can read more about that in the Security section below.
Kchannels has a concept of a channel state: that is the list of all assets managed by the channel, as well as their balances. This structure is usually not being exchanged directly, but appears prominently as an EIP-712 hash in certain places in the system.
Each transaction encapsulates the initial channel state of the user's channel, as well as the final, the one after the transaction has changed their channel. In a perfect world the final channel state of a transaction will always align with the next transaction's initial state, as well as the initial channel state of the current transaction given its fee and value components. Thus both the user and their zone will correctly predict the next hash value, all without disclosing what assets are in the channel to anyone else. When this is not the case, the channel is in a dispute and it cannot transact any longer.
With so many checkpoints, in the unlikely event of a discrepancy, the appropriate action will depend on whether or not the client is currently transacting with their channel: if so, a client can immediately fail the transaction that is changing their channel in ways they do not approve of. If there is no ongoing transaction, then there is an unexplained state change, e.g. assets have gone missing without a transaction. In this case they can file a dispute at the smart contract, using the signed transaction summaries as proofs for the correct channel state. Notably, however, such a dispute is never against any of the user's counterparties but against their own zone for allowing such a change. The zone is then responsible for a timely response to the challenge at the smart contract: it will always reply with the transaction summary right after the user's one, if there is one, as well as its own latest transaction summary. The smart contract can then rule on the actual channel state. The ruling is final and non-repudiated: this becomes the new channel state from that moment on. If the zone does not respond to a dispute, the default ruling is in the user's favour and the zone, when it comes back online, has to honor it whatever it is.
In all cases on successfully executing a dispute, regardless of the circumstances or the outcome, the user has the choice to withdraw all their assets at the smart contract level, bypassing all of Kchannels. A non-cooperating zone will therefore simply drive users away, and not deny them access to their assets.
You can read more about Dispute Resolution at the "Dispute Resolution" section below.
Zones can be scaled horizontally by adding additional nodes behind their load-balancer, though this is not the preferred way to scale Kchannels.
The zone-based architecture of Kchannels allows for easy partitioning of a deployment into manageable chunks. This allows for unlimited scale simply by adding additional zones to an active deployment. On adding an additional zone, the zone manager will begin shifting new and updated channels into it, thus distributing channels and assets between all the zones present. This way we can achieve virtually any scale desired.
Furthermore, with zones being our users' access point to Kchannels, we now have the freedom to evolve our architecture using the best practices of the day to further boost availability and scale.
You can read more about Scaling in the dedicated section below.