Test EXTCALL creation gas charge #1025
Conversation
Test the creation gas charge of a contract when the contract was called and remained "empty." Signed-off-by: Danno Ferrin <danno@numisight.com>
| setup_code=Bytecode(None), | ||
| subject_code=opcode(address=empty_address) + Op.EXTCALL(address=empty_address, value=1), |
There was a problem hiding this comment.
Not 100% sure but this layout seems to not discriminate against where ACCOUNT_CREATION_GAS is actually charged - opcode or Op.EXTCALL.
Would an alternative where opcode is in the setup_code make sense? It would require some fiddling with warm/cold (because the baseline code would warm the address), but would be more "by-the-book" I guess
There was a problem hiding this comment.
2nd comment - the idea of gas_test would be to have the pushes in setup_code, decoupling the test from push costs. Note that the situation in the test just above is different
There was a problem hiding this comment.
opcode does not have value passed in as part of the call. so ACCOUNT_CREATION_GAS will not be added to that call.
Also, running an EXTCALL in setup is not side-effect free. A warm cost is embedded and winds up messing up the calculations.
Also, moving the pushes to the setup ruins the readability because you have to then know what values are in what slot, and extra messiness because EXTCALL has an extra argument for value=0 that would need to be conditionally handled.
And the fuzzing failure in Besu was the whole subject code: a call to an empty account that stayed empty, then a call to the empty account that fills it and gets charged the account creation cost.
There was a problem hiding this comment.
This is all true. If those aren't easily fixable, I suggest not using gas_test at all. Just call the thing and compare gas to one calculated by hand (it is effectively what you're doing in the current version anyway). I don't think you're leveraging the gas_test abstraction at all, and in case the test fails for any reason, it will just be harder to debug.
There was a problem hiding this comment.
I would wind up using the key of the gas test, just that I am testing a string of opcodes and not just a single operation. I need "cold" and "warm" execution, as the account existing is what's different from the first an second call. Then I need to measure gas, which requires the whole legacy harness.
Perhaps we need to add to the harness a preamble code option that will be executed and not included in the measurement calculations. This will allow the initial call to the non-existent address to be warmed before the setup code is called.
There was a problem hiding this comment.
Then I need to measure gas, which requires the whole legacy harness
ah, I forgot state_test doesn't allow us to expect gas consumed by tx :(.
preamble_code sounds ok, just easy to be confused with setup_code, so pls make sure it's well documented. Maybe after we merge this, I'll spend some time rethinking and possibly we can make them back into one, I had issues with setup_code before too.
And I would move the second PUSHes to setup, optionality is easy to handle with an + if PUSH else NOOP or ideally - the test parameters, which is what is usually suggested here.
Signed-off-by: Danno Ferrin <danno@numisight.com>
🗒️ Description
Test the creation gas charge of a contract when the contract was called and remained "empty."
🔗 Related Issues
✅ Checklist
mkdocs servelocally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.