I have some questions relating to off-chain interactions and validity checks. I’m not sure if I missed some things and therefore have a wrong view - please feel free to correct me.
A participant in a channel has two basic situations
a) receiving a state from a predecessor
b) proposing a new state (doing the move)
Aspect 1: keeping track of validity of off-chain transitions
When in an off-chain progressing situation, assuming the last supported state relates to a valid transition from the on-chain state, the participant in situation a) would be required to check if all moves from the last supported state are valid transitions.
This is generally necessary, as a predecessor could make a mistake (or try an attack), providing an invalid transition. In off-chain mode, the participants could progress based on that (invalid) state, finally (after one or several ‘complete’ rounds), believe they have reached a finalizable state, which however is not accepted by the on-chain executed forceMove transition rules (and/or the thereof called transition rules of the dApp contract).
This is not the case for ledger channels, as there the transitions are individually checked on-chain an denied if invalid. However, in off-chain mode, every participant is required to ensure complete integrity of the transition sequence for the running ‘round’.
Is this view correct?
If so, this would require the participant to get all transitions from the last supported (and assumed to be valid) state to his move (and also the rest).
He would finally need to check if the resulting supported state of this round relates to a valid transition from the current on-chain state. If so, he can neglect the detailed transition chain (and all older supported states).
Practical approach 1) call the pure function validTransition of the forceMove contract for all the transitions (further discussed below)
Aspect 2: making a valid move in a complex dApp
Suppose a) is done, now b) means making a valid move in a complex dApp, which means determine the correct appData and possibly updated outcome.
We could have the dApp logic not only within the transition rules, but encoded as additional pure functions in the dApp contract, which allow to do a move and returning the updated appData and outcome.
This is different from validTransition, as there the user provides two such datasets. However in complex applications, calculating the dataset for a desired move might be complex. These extra functions however bloat the contract.
Both, approaches 1) and 2) are not really off-chain in the sense that a connection to the chain is required to be able to call the pure functions.
Another approach would be to ‘mirror’ the on-chain contract logic on the participant side (e.g. within the wallet), such that the validity check and calculation of transitions can be executed locally by the participant himself.
This however renders the wallet complex and dApp specific.
A third approach would be to have a local VM in which a copy of the foceMove contract and the dApp contract could be executed.
Another aspect I don’t get so far: with counterfactual approach, we should be able to have participants sign a contract, only uploading it on chain in case of dispute.
How can the foreMove’s pure function validTransition, which depends on the dApps.valid transition be executed?
You see - I’m a bit confused…