Ripple currently supports Payment Channels (PayChan). This allows users to transact in small amounts without reporting each incremental change to the Ripple Consensus Ledger (RCL). Unfortunately, the current scheme has a major limitation when used with Interledger payments: Interledger payments are conditional payments, whereas Ripple Payment Channels only support unconditional transfers of value.
In practice, this means that two parties who wish to settle Interledger transactions over RCL must decide whether the PayChan claim is sent when the Interledger payment is prepared or when it is executed. The difference is that in the former case, the sender takes the risk that the receiver will not actually forward the payment, while in the latter case, the receiver takes the risk that the sender will not actually send the PayChan claim. Either way, one party can trivially defraud the other if it so chooses. However, the maximum damage is limited to the payments that are in flight at a given time.
In order to eliminate this risk, the parties can choose to use RCL's Escrow functionality. In this case, RCL is the judge over payment expiry and the parties have no counterparty risk. This comes at a cost - RCL will charge a fee for each preparation and each execution of a transfer.
It's unfortunate that neither Payment Channels nor Escrow payments are ideal in all cases. Payment Channels are more risky, but much less expensive than Escrow and vice versa. In order to resolve this, conditional channels have been proposed [1]. The idea is that the interaction happens off-chain, but if one of the parties cheats, the outcome can be disputed by submitting evidence to the blockchain. The problem with this approach is that it is impossible to verify after the fact whether an expiry date has been met. In fact the timeout must be even larger than in the Escrow case, because it needs to be large enough not only to submit something to the blockchain and have it be confirmed, but in addition it must allow enough time to detect when a peer has failed in the first place.
The obvious solution is to choose the expiry time so generously that we can submit our claim to the blockchain after detecting a fault and still fall within the agreed-upon timeout. However, this can quickly lead to rather large timeouts: Assume that we can consider a peer faulty or malicious after five seconds. Assume further that we can submit a claim to the blockchain and have it be processed within 15 seconds. This already requires a 20 second timeout. Over three hops, this results in an overall timeout of 60s. As observed by [2], the timeout windows can be collapsed, if several hops use the same blockchain for adjudication. However, this may not always be the case. Long timeouts are problematic because users have to wait for an answer before they can safely retry.
The question is then: Can we do any better?
This document proposes a different way to combine payment channels and escrow: Delegated Channels.
We define a new type of payment channel whose claims contain two balances, instead of one. The low balance represents the sum of all executed transfers, while the high balance represents the sum of all prepared and executed transfers. The claim also contains the public key of a notary.
When submitting a claim, the recipient attaches a signed message from the notary ("notary claim") stating what the actual claim amount is. The notary claim amount must fall between the low and high balance, inclusive. If no notary claim is provided, the low balance is automatically assumed.
The security of this scheme is at least as good as regular payment channels. Only in-flight payments are at risk. But even in-flight payments are only at risk if the notary and the counterparty collude. If the notary key is a crypto-condition, we can use consensus groups of notaries instead of just single notaries.
Since only the notary is involved in adjudicating the expiry, the timeouts merely need to be sufficient to cover the speed at which the notary makes decisions, which is not only better than Conditional Channels (blockchain confirmation time + peer timeout), but also better than Escrow (blockchain confirmation time), assuming the notary is faster and/or cheaper than the blockchain, which is likely since it may be less decentralized and otherwise we would just use Escrow instead.
This scheme allows a wide range of security trade-offs while maintaining very simple blockchain validation rules.
When two parties transact, they have fundamentally two choices: Escrow or no escrow (i.e. PayChan). Delegated Channels add an option in the middle - escrow, but with some lower level of security.
Theoretically, the notary can themselves use a delegated channel to decide the amount. In order words, it is possible to have multiple levels of delegation if desired. For example, a pair of peers may choose RCL Escrow to handle payments over $10000, a Delegated Channel with a 4-of-7 notary group to handle payments over $100, and a centralized notary to handle all remaining payments.
Note that the transaction timeouts can be can be lower for lower tiers of validation and are not constrained by the speed of the top tier system (RCL in the example). The channel timeouts can be larger and must increase from the lowest tier system to the highest tier system, so that a claim can be submitted at the lower tier system while still allowing enough time to then use the result to submit a claim at the higher tier system.
In practice a nested system might not be worth building since having three points on the risk/speed spectrum might be enough. However, note that RCL would not have to change if somebody decided to implement nesting in their notary.
[1] https://lightning.network/lightning-network-paper.pdf
[2] https://arxiv.org/abs/1702.05812