Dispute resolution
A dispute is a situation in which a user is not in agreement with his zone on the most current state of his channel. Unlike in other implementations, a dispute is always between a user and his zone--a strictly local condition, with the rest of the system being able to operate normally.
The dispute resolution process is designed to neutrally and fairly resolve disputes at the blockchain layer. It is always biased in favor of the user and against Kchannels.
Dispute resolution is a well defined protocol for resolving disputes via the Kchannels smart contract. During this process, the user is temporarily unable to send or receive transactions on his channel while his proper channel state is being determined. Any incoming asset transfers (deposits) from Layer1 Mainnet are held, to be processed when the dispute finishes, and any incoming transactions are temporarily turned away.
Kchannels' dispute resolution protocol happens in four distinct stages:
Channel Definition - the most current channel definition for a channel is being determined.
Channel State - the most current channel state is being determined.
Blockchain Handling - the user gets to claim assets from any blockchain transactions their zone either failed to send out, or failed to credit in-channel.
Closure - the user gets a choice between closing their dispute and continuing using their channel with the dispute outcomes above, or to force their channel to close at the smart contract. In the latter case all their assets are returned back to them, bypassing their zone.
The first three stages of a dispute result in decisions being made by the smart contract. A decision made becomes immediately binding on both user and zone, and once made cannot be repudiated. The last stage gives the user the choice to continue using his channel, or to close it permanently.
During the first three stages, the user (channel owner or validator identities only) files a claim, which the zone has to respond to. The dispute process is always biased against the deployment, meaning the zone has to defend its actions before the smart contract and the user, either by countering the user's claim, or by replying with an acceptable action taken. Failing to reply results in a decision in favor of the user, one that cannot be undone. This is an important feature to ensure a dispute process can result in assets released to users even in extreme situations where Kchannels is completely down and unavailable. Also, by creating an "asymmetric" dispute process as explained above, we can put disproportional burden on the zone to reply quickly, thus resulting in a much more expedient dispute process than would normally be possible between two users. The goal is to have dispute processes end within hours at most. Also, due to the localized nature of the dispute process, multiple concurrent disputes on different channels are possible within the same smart contract.
It is important to note that any decision made in a dispute is only binding to that one channel. This is important as if, for example, a transaction between a sender and a recipient is voided by a dispute process at the sender side, the sender channel is restored to the pre-transaction state, but the recipient is free to keep what he got--there is no clawback of completed transactions. This means that any decision against the Kchannels deployment is at the expense of the Kchannels deployment and can potentially throw it out of balance.
A situation where a zone is down is damaging for Kchannels, as there is nothing preventing a user from filing a dispute and submitting an old channel state that favors him. Furthermore, transactions voided by a dispute process are never clawed back from their counterparties, so the deployment can get thrown out of balance.
As our requirement for extreme scaling excludes direct collateralization of the smart contract, both of the situations above can lead to an undesirable situation in which the smart contract does not have enough assets to cover the claims against it. Kchannels addresses this possibility in three specific ways.
First, the system is designed from the ground up to avoid the possibility of a zone being unable participate in the dispute resolution process, including at the software architecture level, the code level, and during operations. In the extreme situation where the zone is unavailable, its "double" at the security layer can reply to challenges against it, thus maintaining the integrity of the deployment in the zone's absence. Most importantly there is every incentive for the system to avoid these exceptional situations, as the user experience we aim for implies high availability.
Second, with the planned security layer in place, Kchannels will maintain a "dispute buffer" at the smart contract - a buffer of funds in each asset supported by the system, which is not claimed by any zone. This buffer is managed internally between a high and low-water mark set at the smart contract. Whenever a dispute results in a judgement against Kchannels, the deployment ends up laying claim to more assets than those deposited, thus allocating funds from that buffer to a zone. Ideally, even if the deployment is unable to cover a claim against its smart contract, that would be quickly remedied the next time the smart contract is topped up.
Third, Kchannels will employ smart contract insurance to further protect against losses. The intention is no matter what happens, users walk away with their funds.
Most importantly, with multiple levels of checking of transaction and zone integrity, the expectation is that the dispute resolution process will be rarely used.
The dispute resolution feature will be released in 2021. Kchannels cannot be considered completely noncustodial or trust-minimized until this feature is released.