minted_amount vs new_contract_balance in the receipt of MINT

[IaroslavMazur]

This discussion is in relation to the following @PaulRBerg's idea in #8:

New receipt of type Mint
Data: asset_id, sub_id, and new total balance of contract

---

@PaulRBerg, why the new total balance - and not the minted amount, though?

Here are several arguments for the latter:

1. Communicating the new total balance runs the risc of being confusing for the consumers of this log/receipt.

   • This is especially true in cases when in between the mints, the minter contract transfers the minted assets to some other addresses (which would be a normal scenario, after all). Imagine, for example, a contract:
     • having a balance of 10,000 assets,
     • minting 10,000 more (increasing its balance to 20,000),
     • tranferring 10,000 assets to various addresses (decreasing the balance back to 10,000) and
     • minting 10,000 more (increasing its balance, yet again, to 20,000).
   • In the above situation, we'd show 2 "different" receipts which would, nonetheless, look the same on the surface (both minting 10k, raising the minter's balance to 20k) and would require more on-chain sleuthing to figure out what has, actually, happened there (e.g. by how much the minter's balance has increased).
   • At the same time, if we include the minted amount in the receipt instead, the above is not a problem.

2. "Reverting" the effects of a tx that couldn't have executed until the end, in revm, is performed, from what I've observed, by manually undoing the respective operations (e.g. crediting the transferred assets back to the Sender and debiting them from the Recipient, in the contect of a simple asset transfer tx).

   • Reverting is much easier when the assets amount that is to be reverted (i.e. that has been minted) can be extracted directly from the MINT receipt - and doesn't need to be calculated explicitly.

3. The total balance of the contract could be fetched separately from the VM, by anyone interested in it.

   • The same can't be said about the minted amount, however, which is only directly accessible during the minting operation.
   • After minting, however, figuring out the minted amount would require:
     • knowing the exact moment in time when the minting happened,
     • fetching the balance of the minting contract 1 block prior to the minting
     • fetching its balance right after the mint and
     • computing the difference between the two.
     • Overall, this would be unreasonably complicated for the insight resulting from this, imo.

Note: originally, I've implemented the JournalEntry::AssetsMinted receipt to include the "new total balance" of the minter, but, then, having had the above considerations (especially the 2nd one), I've changed it to the "minted amount".

Originally posted by @IaroslavMazur in #8 (comment)

[PaulRBerg]

why the new total balance - and not the minted amount, though?

No particular reason. I just produced a conjecture on the spot.

Happy to use the minted amount instead per the argument you have put forth.