Conversation
|
@jjcnn For the purpose of the view of scilla, what we do on the blockchain side is we subtract the balance right before the execution is passed to the scilla interpreter. And add it back after it comes back to the cpp side. This helps us preserve the atomicity of balance as we use |
That won't work, because a contract can remote read the balance of another contract. The semantics we agreed on months ago was that if a contract sends out some messages, then the amounts in those messages are all deducted from the contract's balance before the next message is processed. This is what I refer to as the "cash in an envelope" semantics: the sender creates an envelope for each outgoing message, and puts cash in them. That cash is therefore no longer in the contract's account. This means that if contract A sends two messages, one to contract B followed by one to contract C, then if contract B remote reads the balance of contract A, then the read should result in (A's balance at the start of the transaction - amount in message to contract B - amount in message to contract C). What you are suggesting here is that the result would be (A's balance at the start of the transaction - amount in message to contract B). |
|
@jjcnn I dont totally get your point. Could you perhaps write a test case for that situation |
They're right here: https://github.com/Zilliqa/scilla/blob/accounting_tests/tests/contracts/accounting_tests.scilla |
|
@jjcnn all of these tests pass so atleast the issue is not visible in tests |
Reference: Zilliqa/scilla#1032