[Review] Restore opcode gas costs from Ethereum #367
Closed
gastonponti
started this conversation in
CIP Discussions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Simple Summary
Restore the gas cost of the
SLOAD
,*CALL
,BALANCE
,EXT*
andSELFDESTRUCT
opcodes which diverged from Ethereum.Abstract
Apply the EIP-1884 gas cost changes, that will restore the costs applied in the EIP-2929. Our CIP-48 was created to apply the last one, with reduced costs.
Motivation
EIP-1884 was not applied in the past, because the CELO state was small in comparison to Ethereum’s. This has changed already, and not only do we need to cover ourselves from possible attacks of underpriced operations, but also not having the same gas cost table than Ethereum, generates two issues:
In our new pursue of maintaining the execution layer as close as Ethereum to be able to merge new versions from upstream as soon as possible, this change not only brings us closer to that objective, but also simplifies our e2e tests to verify that everything works as expected.
Specification
Copy the specification of EIP-2929 restoring the changes added in the EIP-1884:
Parameters
SStore
As the
SSTORE_CLEARS_SCHEDULE
changes in the EIP-3529, using the values of the EIP-2929, which also depended of the EIP-1884.The new
SSTORE_CLEARS_SCHEDULE
changes from 6100 to 4800Rationale
There is no specific need to restore the same numbers, and we could discuss a better tuning to reach a more specific gas cost per opcode, but mimicking the same numbers of Ethereum will simplify the code base and reduce the divergence from upstream geth, thereby making Celo clients more maintainable.
Backwards Compatibility
Security Considerations
As with any gas cost increasing EIP/CIP, there are three possible cases where it could cause applications to break:
There are two ways to look at these risks. First, we can note that as of today developers have had years of warning; gas cost increases on storage-accessing opcodes have been discussed for a long time, with multiple statements made including to major dApp developers around the likelihood of such changes. EIP-1884 itself, EIP-2929, or even CIP-48 provided an important wake-up call. Hence, we can argue that risks this time will be significantly lower than the previous CIP-48.
License
This work is licensed under the Apache License, Version 2.0.
Beta Was this translation helpful? Give feedback.
All reactions