-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
feat: introduce block.prevrandao
as alias for block.difficulty
#13512
Comments
Should be consider not making it a blank alias (like we had for I think that would make more sense, as it gives an indication to the user of a potential issue. Of course one can deploy a contract compiled for an older evm version, so it is not bulletproof. |
I think it might be better only to switch between which one is the default depending on the EVM version but still accept both. Otherwise it would be breaking regarding the asm import (we're currently implementing). And would also change assembly output which probably should also be considered breaking since tools may depend on that. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Yeah, the opcode name in assembly output is something to think about. Given that you could restore the previous behaviour easily, makes it less of a severe breaking change. We could also hold off on making paris the default evm version until we have tooling feedback on this... EDIT: also promoting this to |
Just to clarify - this will entail:
Anything else I missed? |
Let's assume to remove the What would happen to the Contracts that were previously using block.difficulty and decided to upgrade (using upgradable SM architecture) from >=0.8.x to the latest one which has this change, and suddenly the compiler throws warning or doesn't compile? |
@mryalamanchi It would not affect upgrades (i.e. storage layout) at all. The compiler should still produce the same exact bytecode even with the new name. At the EVM level the way the opcode works will change immediately with the merge whether we do anything or not. The change in the compiler is simply to reflect that change in meaning but does not itself change that meaning. |
So far the biggest problem seems to be the fact that this would affect portability of third-party libraries. They would no longer be able to provide code that uses |
Decision from the call today: we'll do it the same way Vyper does, i.e.
|
Just as a small addition: on the Yul level this will mean adding |
Aren't we outputting the opcode anyway, which is staying the same? |
Started working on this in https://github.com/ethereum/solidity/tree/paris-oh-paris (no pr yet) |
I meant the name of the opcode, which does change. It's the numeric value used in bytecode ( |
block.difficulty replaced by block.prevrandao ethereum/solidity#13512
Summary
EIP-4399 renames the
DIFFICULTY (0x44)
opcode toPREVRANDAO (0x44)
. The return value of theDIFFICULTY (0x44)
instruction after this change is the output of the randomness beacon provided by the beacon chain.For reference, I implemented this feature in Vyper here.
The text was updated successfully, but these errors were encountered: