Hi @vishwas_hypermine, I think this is a correct representation of the flow.
To answer your question at the first red
??? what happens is:
- FSM checks the received transaction is indeed that was expected. This protects the client form accidently sending the wrong transaction to the FSM
- FSM checks that this transaction had been properly authenticated by the client. This protects the client from accidently sending something erroneously signed to the other party
If there is something wrong here, this is communicated only to the client that initated the update round (left one).
At the second red
??? happens simething similar:
- FSM again checks that this indeed is the expected transaction
- FSM checks that both participants’ authentications are correct
If there is something wrong here, this is communicated only to the client that acknowledged the update round (right one).
What I also saw that is not quite right is at the
sends to receiver for signing again step as the FSM does much more than that. It:
- validates the incoming transaction contents - executes the
updates locally to check if
- balances are enough to cover the off-chain update (with
channel_reserve in mind)
- that the newly produced state tree has the same
state_hash as the off-chain transaction
- that the
round is indeed the correct one
- validates that the authentiaction method being used indeed is valid
If any of the checks fails, then it reports to clients.
Basically the FSM does all the checks required so the clients don’t have to but are yet safe. Assumption is if you have a solid FSM protecting your interest, the other party will be decentivized to act maliciously.
Note that I am using check the authentication method being used instead of validating signatures. This is intentional. If you want to read about signatures,
generalized accounts and what authentication method is being used in the context of State Channels, you can consult the protocol documentation.