Consider removing checkpoint from the contracts

[lalexgap]

Based on discussion over the virtual payment app and checkpoint it's now clear that checkpoint-ing while using the VirtualPaymentApp doesn't make sense.

That prompted us to consider whether we should have a checkpoint function at all. It's not clear that there any strong use cases for it and removing it would simplify ForceMove and reduce the attack service.

We should consider if checkpoint will be useful in use cases we're interested in and if not consider removing it.

[geoknee]

If we do this, let's not forget to update the docs also.

[geoknee]

@NiloCK keen for your feedback on this.

[nksazonov]

So far, the Yellow team has been considering using checkpoint for 2 cases:

1. One party saving their progress before going off-line.

   This party may not know when they will be back on-line, so by checkpointing the latest supported state, they guarantee the channel will not be challenged with an older state.

2. Cross-channel checks

   checkpoint (in fact, on-chain channel data) adds an ability for one channel to check a progress of another one, allowing for creation of more complex applications.

That being said, the Yellow team thinks removing checkpoint from an on-chain protocol would narrow the possible use cases of state channels.

[geoknee]

Thanks for this input @nksazonov!

Case 1 is absolutely the intended application of checkpoint. Case 2 was not anticipated, so I would like to hear more about that.

It may be that we can keep checkpoint and fix the root problem another way. The root problem is that the current VirtualPaymentApp does not really fit the pattern of checkpoint, since it uses replace-by-incentive vouchers and not turn numbers.

If we revert to a "delegated funding" model, we could run virtual channels with turn numbers, along with many other benefits.

[nksazonov]

Regarding cross-channel checks:

In our use case we have a state channel (let's call it clearing channel) that operates with collateral, but does not have funds deposited (so it is non-custodial). After some time a need for settlement arises, and parties have to exchange collateralized funds. One of the options we are implementing is state channel (escrow channel), where parties deposit funds.

Before executing a settlement, parties have to agree on a post-settlement margin (collateral distribution on a clearing channel). Therefore, settlement and applying post-settlement margin (PSM) must be an atomic operation.

Atomicity is achieved by introducing a check in an escrow channel regarding the PSM. Thus, the steps are the following:

1. Parties agree on a PSM turnNum
2. Parties sign a settlementState, which includes PSM turnNum, clearingChannelId and adjudicatorAddress
3. Parties agree and sign postSettlementMargin
4. One of the parties checkpoints the PSM
5. One of the parties concludes the escrow channel by supplying the settlementState 5.1. EscrowApp checks for signatures 5.2. EscrowApp calls adjudicatorAddress and checks on-chain channel data for clearingChannelId to contain turn number not less than PSM turnNum
6. Parties finalize, close and defund the escrow channel, gaining access to traded funds

It would be great to hear your opinion on this!

P.S. For now, we are not using virtual channels due to their complexity, but this will change in future.