If you were to store hashmaps of balances on two canisters and wanted to call transfer between two accounts on separate canisters, there is no way to ensure that this goes through consistently and correctly everytime. Here’s why. I hope someone can rebute me but I believe I am correct.
You have canister 1. And canister 2. A user ask to transfer 10 tokens from user 1 in canister 1 to user 2 on canister 2.
Potential method 1. call other canister before update self
Canister 1 can call the transfer method on canister 2 and drop in the amount of tokens it wants to give up. Canister 2 receives the the transfer, updates user 2’s balance and sends back a notification that the transfer went through and to subtract balance from user 1. The failure point here is that if canister 1 ran out of cycles or space (or any other error) during the awaiting period from canister 2.
Canister 2 now has transfered balance from canister 1 while canister 1 did not update.
Potential method 2. Update self before calling other canister
Canister 1 updates its user balance first. Then sends off a transaction to canister 2 a notification to update canister 2’s user balance. Canister 2 fails and notifies canister 1 to revert transaction. Somehow canister 1 is out of cycles. Canister 1 now has a subtracted balance that was supposed to go to canister 2 but now is not. When someone tops up canister 1, incorrect state has occured.
Note, while I say cycles and storage limits as errors, I really mean any hypothetical errors that could occur between the await communication between c1 and c2.
Anyone have any ideas?
Inb4 utxo model. A Utxo model would work as transactions are always done on one canister. To get a users balance you just run through all archive canisters of transactions and add it up for a single user. However, for defi applications where it may be necessary to run through every holder’s balance and then update every single one as well; this model seems to be extremely slow.