Pure functions vs. in wallet code

Hi Liam,
thank you for your answer; again, highly appreciated.

One aspect related to initial question still puzzles me, It’s about supported states and what needs to be stored by the agent in order to be able to force it later on on-chain.

The tutorial states (in my words)
supported state: has signatures of the n participants (or a valid chain of transitions, signed accordingly).
I will use {i} so signalize its a supported state and {i}* its on chain.

Suppose we have a 3 participant channel, with participants A,B,C and a supported state i on chain:
Now the participants can make their move (_A means A has signed):

{i}* ->(i+1)_A → (i+2)_B → (i+3)_C which gives us a supported state, written short as {j}

in short we have
{i}* ->{j}
and could proceed in the same way to end up in a later supported state
{i}* → {j} → {k}

1. Aspect’s questions
As far as I have understood , the participants could now keep the information related to most current supportet state {k}, and neglect {j}. Is this correct?

I.e.: can we have an on-chain transition {i}* → {k}* by just providing {k}?
Or do we need to keep all intermediary states?

As far as I have seen from the forceMove code, as long as its not related to challenges and finalized=True states, everything signed correctly is a validTransition IF app.validTransition is true.

This means that one needs to be careful with respect to app.validTransition to not produce situations where a valid chain of transitions leads to a supported state (e.g. {k}) which however ist not a valid direct transition from the latest on chain state {i}* - right?

Otherwise the participants would need to keep a long sequence of transitions in long running of-chain channels (or on-chain checkpoint frequently).

Allowing for not storing all transition, bu only the newest supported could mean that we need 2 alternative branches of validTransition checks in the app code.

IF transition from one state to the next (in the sense of usual mover transitions, so to say atomic transition): apply the game logic to check if e.g. the change in outcome is OK

ELSE IF we have a transition from one supported state {} to another, later (larger turn number)
return true if the second state is really a supported state. Do not check game logic, as we only have a resulting outcome and no detailed individual moves. But this is ok, as every participant signed that state.

Or am I wrong on all of this?

Sorry for the many weird questions…

Alex

P.S.: I decided to move the 2nd aspect to an extra topic, to keep things a bit more manageable