Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Retrieving Transactions does not verify code/abi version #544

Closed
brianjohnson5972 opened this issue Oct 5, 2017 · 2 comments
Closed

Retrieving Transactions does not verify code/abi version #544

brianjohnson5972 opened this issue Oct 5, 2017 · 2 comments

Comments

@brianjohnson5972
Copy link
Contributor

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).

@brianjohnson5972
Copy link
Contributor Author

I think as we look at this we should also consider Brooks Boyd's question on EOS Developers telegram group about altering contracts.

@brianjohnson5972
Copy link
Contributor Author

#3413 is a more current identifying of this, closing this issue since it is a duplicate.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants