At present the expect section only has accounts and their attributes (balance, nonce, code, and storage). This means we can only test results that are visible to the evm.
It would be useful to have additional information available, which retesteth gets (or can get) from t8ntool. Specifically, we could use visiblity into:
- Information from
--vmtraceraw. For example, it might be useful to specify that when contract A is executed, when the program counter is B, the stack should have these values: [... , ... , ...], or that the gas spent between PC=x and PC=y is
a certain amount.
receipt.logs, the log entries emitted. Right now so the only way to check what they are is to write a blockchain test and look in the hash of the block where they are emitted to see it is the expected value (see https://github.com/ethereum/tests/blob/develop/src/BlockchainTestsFiller/ValidBlocks/bcStateTests/logRevertFiller.yml). This method is very susceptible to false positives, because any other change in the block also changes the hash.receipt.transactionHash, which lets us verify that everything ran as expected.
At present the expect section only has accounts and their attributes (balance, nonce, code, and storage). This means we can only test results that are visible to the evm.
It would be useful to have additional information available, which
retestethgets (or can get) fromt8ntool. Specifically, we could use visiblity into:--vmtraceraw. For example, it might be useful to specify that when contract A is executed, when the program counter is B, the stack should have these values: [... , ... , ...], or that the gas spent between PC=x and PC=y isa certain amount.
receipt.logs, the log entries emitted. Right now so the only way to check what they are is to write a blockchain test and look in the hash of the block where they are emitted to see it is the expected value (see https://github.com/ethereum/tests/blob/develop/src/BlockchainTestsFiller/ValidBlocks/bcStateTests/logRevertFiller.yml). This method is very susceptible to false positives, because any other change in the block also changes the hash.receipt.transactionHash, which lets us verify that everything ran as expected.