Just splitting this out from this thread about scalability: Scalability of update calls in a common scenario
Could you explain a bit more how this interacts with blockchain blocks and cross-canister calls?
My naive view is that incoming calls, whether from outside or inside the IC, wait in some kind of mempool, until they’re processed and accepted into a block. Block consensus imposes some minimum latency of a few seconds on each block and on all the requests within it.
For argument’s sake suppose the call takes negligible CPU time.
It seems like you would still have some scaling limits to do with capturing the incoming requests and their results in the blockchain and coming to consensus on them?
In particular, what happens if the top-level request triggers some quasi-blocking messages to other canisters?
I’m not sure, but it sounds like Paul is saying that all the batch input is collected before processing begins?
That would seem to imply that the outgoing messages can’t be processed until the next round, which means a multi-second delay per step of fan-out? But then, the top level call cannot produce any result in the block where it’s originally enqueued: it’s still awaiting a result. Does it get retried in a later block?
On the other hand, if the subsidiary requests are processed in the same block, that seems to allow blocks to grow without bound in both space and time…?