This is a huge work in progress. Lots of redesign needs to happen before this is ready to merge.
As of now, the network is maintaining a priority queue of messages. The priority of these messages is determined by some function that should be specified to the network. (Note that it is possible to have the priority of these messages change as things progress if that is wanted.) They are also prioritized by the "step" on which they will be delivered. A message with a lower step number will be delivered to its respective recipient before a message with a higher step number.
Furthermore, this function that determines the step that the messages are delivered on can be specified pairwise between any two validators. This is likely the most general model of connectivity that we will need (and one can imagine this being used to simulate peering, etc).
Here are some examples of network models we could simulate:
A synchronous model where every message is delivered by some bound specified to the network. (note, to some degree this means steps are essentially time. I'm not totally comfortable with this yet, but we will see).
A partially synchronous model, where there every message is delivered by some bound that is unknown to the network.
A totally asynchronous network, where every message is delivered by some time infinitely in the future (maybe specified by some probability distribution).
However, to this work, it seems we need to specify liveness strategies for the validators. As of now, the naive way of making blocks is kinda absurd (and we never actually build a blockchain). I'm not totally sure what the best way to do this is, though...
Going to keep this open for now. Likely will close and reopen a new PR - but want to keep this as a light implementation guide if we decide to pursue something like this.
This is a huge work in progress. Lots of redesign needs to happen before this is ready to merge.
As of now, the network is maintaining a priority queue of messages. The priority of these messages is determined by some function that should be specified to the network. (Note that it is possible to have the priority of these messages change as things progress if that is wanted.) They are also prioritized by the "step" on which they will be delivered. A message with a lower step number will be delivered to its respective recipient before a message with a higher step number.
Furthermore, this function that determines the step that the messages are delivered on can be specified pairwise between any two validators. This is likely the most general model of connectivity that we will need (and one can imagine this being used to simulate peering, etc).
Here are some examples of network models we could simulate:
However, to this work, it seems we need to specify liveness strategies for the validators. As of now, the naive way of making blocks is kinda absurd (and we never actually build a blockchain). I'm not totally sure what the best way to do this is, though...