Tooling support for `DIFFICULTY` to `RANDOM` change

[haltman-at]

There's the question of how we can make sure that external tools such as disassemblers and debuggers can properly handle the change of opcode 0x44 from DIFFICULTY to RANDOM (EIP-4399), as I mentioned here.

[mkalinin]

What potential issues with disassemblers related to this change do you see? Is this only a matter of representing the name of the opcode and the data it returns after the Merge? From my perspective representation of the return value should merely be the same.

cc @axic

[axic]

It should not pose any issue to compilers/disassemblers as long as the number of inputs/outputs do not change. It may be annoying to see DIFFICULTY as a text instead of RANDOM.

It can be changed similar to the SHA3 renaming, where different tools changed it at different times.

However it is slightly more annoying as now tools would need to know what EVM version (protocol update) is being used in order to display the correct name, so I would imagine tools choosing one or the other name.

[haltman-at]

As I see, the issues are as follows:

1. Unlike the renaming of SELFDESTRUCT, and other similar proposed renamings, this is not merely a change of name but also a change of function. As such, presenting the wrong name could be misleading; this is the reason I am somewhat uncomfortable with simply picking one of the two names, because it would not correctly describe the function in the other cases.
2. Displaying the correct name requires knowing the EVM version, information which is not always available.
3. If the output of such a tool is to be fed into something else, it may not be acceptable to use a hybrid like DIFFICULTY/RANDOM.

[timbeiko]

We agreed on ACD130 to not make changes at the protocol level to address this issue. Closing for now.

[mkalinin]

In addition:

• Assuming there is a negligible number of cases where DIFFICULTY opcode is required to return difficulty property, this opcode may be renamed to RANDOM disregarding the context; the only change in this case would be the size of the return value, not the semantics. Though, not sure whether this assumption is held or not.
• Theoretically, RANDOM may be discerned by the size of the output (> 2**64). But it might be impractical as decompilers not necessarily execute the code and have access to the return value.