Correct. The update/query call distinction doesn’t even exist for inter-canister calls.
Not possible in the current architecture, precisely because it breaks determinism.
One can imagine a “fast path consensus for non-mutating calls” that would provide a middle ground, but that is far future work.
You need to distinguish between the system certificate (which is CBOR as per the Interface Specification), and which contains only the “root hash” of the application’s data structure, and the application’s certificate, which of course is completely up to the application.
I don’t follow what the use case is here?
Why? Verification only happens on the client side, and Motoko is (so far) purely a canister-side language.
No, it has to use the system API. Data on calls is intentionally not exposed there (it’d be a layering violation), the same way a Unix application using TCP doesn’t see IP packets or sequence numbers.
The system certificate can and should be obtained via the system API, and in Motoko via the
So my suggestion for a Motoko service that certifies it’s query calls is to use a library like my motoko-merkle-tree, and use the built in Candid support to transfer the witness (a.k.a. pruned tree) to the client, where you can turn it into the “decoded” data structure used by the JS library for verification. This way no CBOR is needed.
For certified HTTP assets, some simple CBOR and base64 encoding needs to be written first, indeed.