-
Notifications
You must be signed in to change notification settings - Fork 784
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
EIP 1052 EXTCODEHASH #326
EIP 1052 EXTCODEHASH #326
Conversation
lib/opFns.js
Outdated
stateManager.getContractCode(address, function (err, code) { | ||
|
||
if (runState._precompiled[address.toString('hex')]) { | ||
cb(null, new BN(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If non-existent account has a result 0, while empty code has the empty keccak256, why is the hash of the precompile 0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think that this is a way to signal that the contract shouldn't be calling EXTCODEHASH
on a precompile address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see how this would be confusing behavior. maybe the result of calling EXTCODEHASH on a precompile should be KECCAK256_NULL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be the empty code hash for precompiles, since the account does exists.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. It seems Geth is the only client that has implemented this EIP so I will look over the behavior there.
Rebased this to latest |
What is the status of this? |
Current state here: tests from ethereum/tests#484 are not yet merged, so test result stays the same. |
What's the status of this? |
@5chdn I will today do a new release on the We should then be able to complete here within a week or so and hopefully do a release at the end of next week of we are lucky (this also depends on 1-2 other outstanding changes). Out of interest: what is your connection on (need for) this? |
I just checked all clients in the tracker against Constantinople readiness and this is the last open PR. :) No pressure :) |
Rebased this, this will now run some initial |
Results in: ok 770 the state roots should match
# file: extCodeHashCALL test: extCodeHashCALL
/home/circleci/project/ethereumjs-vm/dist/runCode.js:243
throw e;
^
TypeError: stateManager.exists is not a function
at EXTCODEHASH (/home/circleci/project/ethereumjs-vm/dist/opFns.js:304:18)
at runOp (/home/circleci/project/ethereumjs-vm/dist/runCode.js:237:27)
at /home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:3880:24
at replenish (/home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:1011:17)
at /home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:1016:9
at eachOfLimit (/home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:1041:24)
at /home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:1046:16
at _parallel (/home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:3879:5)
at Object.series (/home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:4735:5)
at iterateVm (/home/circleci/project/ethereumjs-vm/dist/runCode.js:138:11)
at next (/home/circleci/project/ethereumjs-vm/node_modules/async/dist/async.js:5223:28)
at runCallback (timers.js:810:20)
at tryOnImmediate (timers.js:768:5)
at processImmediate [as _immediateCallback] (timers.js:745:5) |
Rebased this. |
I would love to take a closer look on this if nobody else is working on it :) Also on another note I found some weird behaviour with
vs
Is this known or should I open an issue? |
@rmeissner Feel free, that would be great! 😄 jsontrace: This is not known and you should open an issue. |
Side-note: I am currently targeting a VM release mid or end of next week. |
if (err) return cb(err) | ||
if (!exists) { | ||
return cb(null, new BN(0)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mattdean-digicatapult, short note: what occurred to mean when having a short look on how to update here regarding StateManager
: we should make it clear in the docs especially for the the get* methods (so getAccount
, getContractStorage
,...) what the behavior is when called on a non-existing account (will it throw or not, what is returned).
Think it would also not be overblown to have additional test cases for that. If you don't want to do yourself you can also alternatively open an issue on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, I've started working a bit on the documentation so I'll make that clear. If I find too many inconsistencies for the missing values I might make some changes as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. 😀
I removed the check for precompiles, because this is what I saw when I looked at go-ethereum, also this seems to be satisfying the tests :D Also right now I use the |
Can some of these commits be squashed? |
Whew, just 1 (!) failing test on the |
@axic I think actually all. @rmeissner can you do that? |
add EXTCODEHASH rules for nonexistent accounts and precompiles . Replace removed state manager method Fix lint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now, thanks!
Closes #357.