Message verification
How do I verify that an update message was accepted, and that the expected state transition has occurred? @enzo you mentioned merkle proofs being an option, do we have any clarity on what that will look like?
Code verification
How do I verify that the canister I’m interacting with does what I think it does? Assuming the code is open source, how do I check that the compiled Wasm matches the deployed actor? Something like a retrieve function for all canisters should work.
Another question:
Message ordering
I believe messages in a block are first ordered and then executed, right? How is the message order determined?
Hello Norton,
First, a clarification: Update queries go through consensus. Read only queries don’t need to wait so the following does not apply to them.
I believe that update messages are executed on a first come, first served basis, with the caveat that there may be some reordering before the messages get to the selection. There is not, at present, any fancy ordering. Many canisters do run in parallel though, so messages to different canisters are quite likely to be executed out of order.
Note: Given that the order is not guaranteed, if you care about the ordering either the canister needs to enforce ordering or the caller needs to verify that one message has completed before sending the next.
Best wishes, Max
Regarding the status of a message, is this what you are looking for? https://sdk.dfinity.org/docs/developers-guide/cli-reference/dfx-canister.html#_dfx_canister_request_status
Right, I’m only referring to update queries here. My concern is the classic front running problem - assuming a malicious replica can read the contents of my message, it can reorder the pending messages (and add its own messages) for its own benefit. One way to prevent this is to commit to an order before execution, so the malicious replica doesn’t know which messages it can frontrun.
Regarding message verification, I’m asking how I can verify that my expected state transition S -> S' occurred, without any unintended side effects.
One way to prevent this is to commit to an order before execution
Execution has to be deterministic across all replicas. Modifying execution order on a single replica will only lead to a state that is different than other replicas, and hence it won’t be certified.
What a malicious operator can do is to purposely craft a block to use a certain order for their own benefit. However, because block makers are randomly selected, so the effect of doing this to target attack a certain user or a certain canister is limited.
What a malicious operator can also do is to favor one block over another during notary sigining. But this is also likely to have any effect because (1) the rank of blocks are also randomly determined, and (2) a block is fully notarized when it gets majority signatures, so it is unlikely that majority are all malicious.
Does the above answer your question?
Ah right, I forgot about the random block makers, that answers my question.
Is there a way for a malicious actor (not replica) front run a message? They would have to be broadcasted that message relatively early, and then broadcast their own message faster, somehow.
So a malicious operator could give a malicious response to a query request?
So a malicious operator could give a malicious response to a query request?
Yes, it indeed is a valid attack. IC can mitigate this attack in a number of ways, including offering partially verifiable replies for query calls, Such advanced features have yet to be made fully accessible to developers.
As a fallback, one can just use update calls if high degree of security is required.