-
It is difficult to ensure atomicity when multiple canisters are involved in a transaction: for example one of the canisters involved, say the service, may have its input queue full and calls may fail. So some retry logic would be needed, or some two-phase commit involving the ledger would have to be in place. We did have some discussions regarding two-phase commit protocols but are right now not on top of the agenda.
i should highlight that having the ledger as part of a multi-canister call tree (e.g. what we get now using notify ) does not solve the problem since, to keep complexity low and state manageable we do not implement retry logic in the ledger for notify calls that failed and it’s up to the caller to “re-notify” the recipient. -
Very good and important point! In general and data that is exposed via unreplicated query calls should be considered untrusted. What we use for the ledger is just an instace of using certified variables: the ledger is mantained as a hashed chain and we set the hash of the tip as a certified variable. The IC will then return (if asked) a certificate which can then be used to verify that whatever was hashed is genuine, i.e. comes from the IC. One can imagine other hashing schemes (e.g. a Merkle trees balanced one way or another) depending on the application.
6 Likes