If transactions are retrieved using the account history API, they will be prettified using the code's abi. But if this code/abi has been since updated, then the reported json description of the message will be erroneous, unless you are lucky enough to cause an exception.
A less likely (but still relevant) problem exists for writing irreversible block transactions to an external DB ( #172 ). A setcode call could change the code/api after transaction is written to block, but before it is irreversible.
This would could be solved by adding a code/api version to the Transaction Message. There is already a code_version which is a hash of code string, but we wouldn't want to send the 256 bytes for the hash sha. Could use just a portion of hash (similar to refBlockPrefix), but that would require sender to retrieve code/abi to get code_version. Or could require setcode message to also provide a uint32_t version number that we would require to increase (so not repeat).
If transactions are retrieved using the account history API, they will be prettified using the code's abi. But if this code/abi has been since updated, then the reported json description of the message will be erroneous, unless you are lucky enough to cause an exception.
A less likely (but still relevant) problem exists for writing irreversible block transactions to an external DB ( #172 ). A setcode call could change the code/api after transaction is written to block, but before it is irreversible.
This would could be solved by adding a code/api version to the Transaction Message. There is already a code_version which is a hash of code string, but we wouldn't want to send the 256 bytes for the hash sha. Could use just a portion of hash (similar to refBlockPrefix), but that would require sender to retrieve code/abi to get code_version. Or could require setcode message to also provide a uint32_t version number that we would require to increase (so not repeat).