This is a follow-up PR from #827 . In this PR we make the standalone engine reuse the logic that was isolated from the contract in that PR. One key thing to notice about this change is the raw bytes that would be passed to the on-chain contract as input are now also passed to the standalone engine. This will help enable the hashchain to work identically both on-chain and off-chain. Additionally, the output from all methods is captured in the IO instance. We do not yet make use of this, but in a follow-up PR this will also be a necessary feature to ensure the hashchain works properly.
Performance / NEAR gas cost considerations
N/A standalone engine changes only
Testing
Existing tests.
Additional information
Note: the TransactionKind::raw_bytes method is only used in tests and for backwards compatibility. After a full re-index of the Borealis state (which will be needed to compute the hashchain history anyway) this method will not be used in production (i.e. we are not de-serializing + re-serializing the input on every transaction, that would be very inefficient).
Description
This is a follow-up PR from #827 . In this PR we make the standalone engine reuse the logic that was isolated from the contract in that PR. One key thing to notice about this change is the raw bytes that would be passed to the on-chain contract as input are now also passed to the standalone engine. This will help enable the hashchain to work identically both on-chain and off-chain. Additionally, the output from all methods is captured in the IO instance. We do not yet make use of this, but in a follow-up PR this will also be a necessary feature to ensure the hashchain works properly.
Performance / NEAR gas cost considerations
N/A standalone engine changes only
Testing
Existing tests.
Additional information
Note: the
TransactionKind::raw_bytesmethod is only used in tests and for backwards compatibility. After a full re-index of the Borealis state (which will be needed to compute the hashchain history anyway) this method will not be used in production (i.e. we are not de-serializing + re-serializing the input on every transaction, that would be very inefficient).