search

dreamcatcher-tech / dreamcatcher-stack

https://dreamcatcher.land
1 stars 0 forks source link

write the statechart that describes the interblock protocol #78

Open inverted-capital opened 2 years ago

inverted-capital commented 2 years ago

The protocol by which each chain processes messages and transmits them should be declared as a statechart. This statechart should be used to conduct model based testing.

The current core should then be shifted to almost be driven by this protocol definition.

inverted-capital commented 2 years ago

I think the problem is the system is designed to take the covenant interactions with the system, and the system processing of incoming actions from other chains, and then figure out what to do about them, where the figuring out is done as a large collection of statecharts, with the fallacy being they all make instant transitions, so the system output is predetermined for each input. The power of statecharts is modelling how to respond to events where we do not know what is coming ahead of time, but that is not how they are used here.

How things should be, is that the covenant interactions with the system, and the incoming actions of others chains interactions with the system, should all be modeled as state transitions. We do not know what the next transition will be, as this is the source of novelty in the system. The system layer should be modelled as a statechart, and the behaviours of the covenant and remote chains should be state transitions within the system.

State transitions are:

  1. Covenant returns a promise and a bundle of zero or more actions that it wants dispatched - system transitions to pending
  2. Covenant returns json and a bundle of zero or more actions that it wants dispatched - system comes out of pending
  3. DMZ receives a system command - currently is a reducer but should be a statechart with the state stored in the meta slice
inverted-capital commented 2 years ago

The lifecycle of a channel withing a chain should be expressed in this statechart, too, so it is obvious what state in its lifecycle a channel is in:

  1. unresolved
  2. resolved
  3. removed
inverted-capital commented 2 years ago

from @dougbear : the layout of the block should be harmonized with the layout of the state machine that controls each piece. From looking at the type structures, the two should be easily recognized as images of each other.

The block should be the context of the state machine, scoped by nested state.