-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General State Tests Proposal #176
Comments
It would be great if the test contained the chain configuration, containing the fork settings to be used for the test: {
"configuration": {
"homesteadBlock": "0xaabb",
"eip150": "0xaabb"
}
} |
I would like to add all things that are hex should start with |
right. all fields that are hex start with 0x - that is already implemented @obscuren |
https://github.com/ethereum/tests/blob/develop/VMTests/RandomTests/randomTest.json#L14-L15 |
VM tests has not been updated. especially random VM tests. |
Can you explain what are |
Indexes section describes which values from given array to set for transaction before it's execution on a pre state. Transaction now has data, value, and gasLimit as arrays. post section now has array of implemented forks. For each fork it has another array of execution results on that fork rules with post state root hash and transaction parameters. |
I think that
|
I've already wrote the parser :) |
Remember that everyone will have to create similar parser after you, so simpler is better. |
Do we need to care that much about making any new pre-Spurious Dragon tests? IMO if a client incorrectly implements or even omits some pre-Spurious feature, as long as it syncs the blockchain and it has fully correct behavior post-Spurious then we should consider it fine. I'd even say that the only tests we should still be keeping in the tests directory are (i) tests for the current active protocol version, and (ii) tests for the next one. With this in mind, is changing test formats still that valuable? OTOH I do really like the idea of putting data fields into arrays like that to create many de-facto tests out of one. |
ok first. this upgrade is not about making new tests for concrete fork. second. we do need tests for previous forks for two reasons. here are the tests |
We finally got around to implementing this in go-ethereum and there are a few issues with this format:
To fix these, I propose that the format should be changed as follows:
|
we have to agree on a max logs length. one test could have up to 20 transactions in general. |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Specification
General State Test:
Indexes section describes which values from given array to set for transaction before it's execution on a pre state. Transaction now has
data
,value
, andgasLimit
as arrays.post section now has array of implemented forks. For each fork it has another array of execution results on that fork rules with post state root hash and transaction parameters.
all value fields are in hex and prefixed with '0x'
address, secretKey and hash fields are not prefixed with '0x'
Rationale
Due to the recent network changes it would be good to make state tests more general so we don't need to copy them each time a new hard fork occur. The new tests would have a single filler for a single test.
One test per file. So instead of previous
stInitCodeTest.json
file with lost of tests it would bestInitCodeTest
folder with files describing every individual test fromstInitCodeTest.json
.The new format will have results of a transaction execution on every implemented hardfork and in addition it would also allow to describe multiple transaction parameters such as
array of data
,value
andgasLimit
. Thus transaction would be executed with different parameters on a single pre state. This allows to test range of test cases where we need to check x, x+1, x-1 values results.The text was updated successfully, but these errors were encountered: