There is no concrete design for certified queries, so I am going to speculate here. If we disallow cross-subnet calls, then I don’t see any blockers. I think the existing prototype would work also for certified queries. If we support cross-subnet calls, then we probably need multiple rounds of consensus, which would increase the complexity of certified queries but at the same time would allow signing of the cross-subnet messages (as @nomeata noted in the very first comment of this thread).
Also, I hate to ask this, but assuming option 1 is favored by the community (perhaps in a proposal vote), when do you expect ICQC to be generally available? Would it be in a matter of 1-2 months or much much longer?
In terms of engineering work 1-3 SWE-months sounds like the right ballpark. Please note that this doesn’t directly translate to real months because there are other high-priority projects queued up and the teams are overloaded.
Some of the remaining work:
Since the calls are limited to the same subnet, we would need some mechanism to create canisters on the same subnet and also keep them together in case of subnet splitting. I think this is the main blocker.
We need to consider whether we want to introduce some way of charging for queries because the execution cost of all queries is going to increase significantly. That’s because we don’t know beforehand whether a query is going to call another query or not, so we would have to keep track of modified memory for all queries. (We could also introduce some annotation for developers to indicate that a query is going to use ICQC, but that seems a bit ad-hoc to me).
We need to introduce limits to guarantee that all queries terminate within a reasonable deadline.