This question is about IC’s block producing mechanism.
AFAIK, IC’s block consists of only messages that are sent to canisters. Whether these messages are initiated by human user interaction or inter-canister call, they’re treated alike and bundled into blocks by proposer nodes.
I’m aware of that IC does not guarantee message order due to the random rank of block proposer in each round. However I still want more insight into how messages are ordered in a particular block from the proposer’s POV.
I’mma describe my current understanding below. I hope someone familiar with the topic can help fact-check this description. For simplicity, let’s consider only the normal case, assuming there’s no adversary nodes in the subnet, everyone is honest.
- Each round, one block with be notarized and be persisted on-chain. Ideally this block should be proposed by the node with rank 1 in current round. Let’s assume eventually node with rank 1’s proposed block is accepted, and inspect its POV.
- During block time, node rank 1 will listen and collect messages to include in its draft block-to-propose.
- When it receives a user initiated message, which can come from direct user interaction via internet request, or intra-subnet message propagation from peer nodes, it will invoke the message against corresponding canister, and collect all “internal messages” generated by inter-canister calls along the way.
- Each user message, together with the internal messages induced by this particular user message, should be viewed as a “group” and are guaranteed an ordering because of causality.
- Messages of the same aforementioned “group” are sequential, it’s not possible to see other user messages from other interaction in between. They’re also guaranteed to be packed inside same block, it’s not possible to span multiple blocks.
This is my understanding. I hope someone from the core team can shed some light, let me know if this mind map is right or wrong. If wrong please help correct me. Thanks!
I’m particularly interested about point 5, cus if that’s not the case, it implies race condition can happen anywhere, anytime.
Imagine Alice submit a request, and she is in the middle of an interaction, which spans multiple inter-canister steps, produces multiple messages, meanwhile Bob can somehow end up “inserting” his message in between, which could cause state mutation. Boy, that’d be a big big problem. Then I must ask how to deal with such situation were it the case.