-
Notifications
You must be signed in to change notification settings - Fork 746
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
VM: Custom precompiles #1813
VM: Custom precompiles #1813
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
Hardhat tests are failing and should be fixed |
Can this get a short analysis if a fix can be applied quickly or not (and then optimally also an update on the fix 😋, but first task would also already bring this further, slowly starting to think about the next small release round, mainly to bring EIP-1153 in on request)? |
Have moved this back to |
This should fix it, but let's see. I am also suddenly getting local lint errors but that might be because I'm on a different version (the This can definitely get into the next release, will fix today. |
OK, this fixes the hardhat e2e tests, but in c168dd7 it created an issue on CI on client which we cannot reproduce locally. Thoughts? Note that in the commit before that: da1f81b this error was not there, and all tests passed except hardhat e2e. The test failed because upon setting up each test, |
Tests pass, ready for re-review |
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 except you have an open TODO so wanted to understand if we need to wrap that up before merging?
const check1 = getActivePrecompiles(this._common).find((a) => a.equals(address)) | ||
const check1 = getActivePrecompiles(this._common, this._customPrecompiles).has( | ||
address.buf.toString('hex') | ||
) |
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.
This very much feels like the wrong abstraction to me to bake the precompiles even more into StateManager
, I guess this was suboptimal from the beginning to have this getActivePrecompiles
call in here.
This becomes even more apparent regarding the upcoming StateManager
extraction.
Would it be a way to generally remove this check1
and instead add the precompiles (e.g.) to the passed in addressesRemoved
array? 🤔
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.
Ah right, I don't know why I added this, it should not be there. I think I had in the original PR also the remark that we should probably wait for the state manager to be extracted.
I have blocked the PR, I wanted to say let's wait for the extracted state manager but we can't do that since we are pointed to The reason precompiles are added is because they are used to generate an access list. You do not need to add precompiles since these are in the access list by default (they are always warm addresses). We could disable this on master but then it would break things. The alternative is to move this |
Can't we just pass in the precompiles from the outside to the method as I suggested above? 🤔 |
@holgerd77 I somehow misread that, you are right, that'll definitely work and is really clean. Will do 😄 |
Done @holgerd77! |
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.
LGTM, great, thanks Jochem! 😄
Cherry-picked from #1806