You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: