State channel communication validation

æpp Development SDKs
1

Hi guys I tried debugging the sdk for better understanding of state channel. I came up with this flow. Can someone please validate it. If my understanding it correct?

Also, since I did not debug the FSM module, I have no idea whats going in there. I am assuming it as a black box for now. It would be really great if you can reply whats going on there at ??? steps. It is like storing states or what else?

image
image1230×1103 70.7 KB

1 Like
2

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.

1 Like
3

Hey @dimitar.chain thank you for quick response.

1 Like
4

Keeping it here for further reference

image
image1342×1327 103 KB

4 Likes
5

@vishwas_hypermine actually I see a missing piece right there: just after 2.5 the receiver sends the co-authenticated transaction to the sender. Right there is a missing step that is similar to 2.5 - the FSM of the sender receives the co-authenticated transaction and it validates that:

  • this indeed is the transaction that was expected
  • it is properly signed by both parties

This is a crucial step that keeps the sender safe as well.