I haven’t done a complete tear down of how the IC handles messages yet, so please correct me if I’m making poor assumptions.
In eth all the nodes have to agree that a block is valid. There for the block has to provides some assumptions about what it used to calculated the message order and set of state changes. One of these things is the system time (now) that can be used in code and all messages in that block share a reference that value. It has to be greater than the time provided by the last block. This keeps “now” from going backwards. If message 1 updates a var to “now” and other functions gate on now<var only one message call will be allowed in that block.
My assumptions in the IC is that there is a subset of elected nodes that are going to be responsible for authorizing the equivalence of a block on the IC for that canister. If n>1 of elected nodes they will eventually have to agree on state changes and if they have different system times that determine now they will tell each other to piss off. They could still agree on message ordering, but state won’t ever match. That system time value needs to be share as part of the state change work checking or it won’t be deterministic. Maybe this time changes as async come back? Perhaps calls can cross “blocks” in this way?
I’ll labor to understand better, but I’ll still contend that a systematic way to reference the block.message of the executing canister and the beacon chain would be useful in a number of systems.