|Author||Mikhail Kalinin, Danny Ryan|
Table of Contents
- Including randomness output in the block header
- Using mixHash field instead of difficulty
- Reusing existing field instead of appending a new one
- Reusing the DIFFICULTY opcode instead of introducing a new one
- Renaming the field and the opcode
- Using TRANSITION_POS_BLOCK rather than a block or slot number
- Using 2**64 threshold to determine PoS blocks
- Backwards Compatibility
- Test Cases
- Reference Implementation
- Security Considerations
This EIP supplants the semantics of the return value of existing
DIFFICULTY opcode and renames the opcode to
The return value of the
DIFFICULTY opcode after this change is the output of the randomness beacon provided by the beacon chain.
Applications may benefit from using the randomness accumulated by the beacon chain. Thus, randomness outputs produced by the beacon chain should be accessible in the EVM.
At the point of
TRANSITION_POS_BLOCK of the Proof-of-Stake (PoS) upgrade described in EIP-3675, the
difficulty block field MUST be
0 thereafter because there is no longer any Proof-of-Work (PoW) seal on the block. This means that the
DIFFICULTY opcode no longer has it’s previous semantic meaning, nor a clear “correct” value to return.
Given prior analysis on the usage of
DIFFICULTY, the value returned by the opcode mixed with other values is a common pattern used by smart contracts to obtain randomness. The instruction with the same number as the
DIFFICULTY opcode returning the output of the beacon chain randomness makes the upgrade to PoS backwards compatible for existing smart contracts obtaining randomness from the
Additionally, changes proposed by this EIP allow for smart contracts to determine whether the upgrade to the PoS has already happened. This can be done by analyzing the return value of the
DIFFICULTY opcode. A value greater than
2**64 indicates that the transaction is being executed in the PoS block.
TRANSITION_POS_BLOCKThe definition of this block can be found in the Definitions section of EIP-3675.
TRANSITION_POS_BLOCK, client software MUST set the value of the
mixHash, i.e. the field with the number
13 (0-indexed) in a block header, to the output of the randomness beacon provided by the beacon chain.
DIFFICULTY opcode, i.e. the EVM instruction with the number
0x44, MUST return the value of the
Note: The gas cost of the
DIFFICULTY opcode remains unchanged.
mixHash field SHOULD further be renamed to
DIFFICULTY opcode SHOULD further be renamed to
Including the randomness output in the block header provides a straightforward method of accessing it from inside of the EVM as block header data is already available in the EVM context.
Additionally, this ensures that the execution layer can be fully executed with the block alone rather than requiring extra inputs from the PoS consensus layer.
Mixing the randomness into a block header may contribute to uniqueness of the block hash in the case when values of other fields of the block header match the corresponding values of the header of another block.
mixHash header field is used instead of
difficulty to avoid a class of hidden forkchoice bugs after the PoS upgrade.
Client software implementing pre-EIP-3675 logic heavily depends on the
difficulty value as total difficulty computation is the basis of the PoW fork choice rule. Setting the
difficulty field to
0 at the PoS upgrade aims to reduce the surface of bugs related to the total difficulty value growing after the upgrade.
Additionally, any latent total difficulty computation after the PoS upgrade would become overflow prone if the randomness output supplanted the value of the
mixHash field is deprecated at the PoS upgrade and set to zero bytes array thereafter. Reusing an existing field as a place for the randomness output saves 32 bytes per block and effectively removes the deprecation of one of the fields induced by the upgrade.
See the Motivation.
The renaming should be done to make the field and the opcode names semantically sound.
TRANSITION_POS_BLOCK to trigger the change in logic defined in this EIP rather than a block or slot number, this EIP is tightly coupled to the PoS upgrade defined by EIP-3675.
By tightly coupling to the PoS upgrade, we ensure that there is no discontinuity for the usecase of this opcode for randomness – the primary motivation for re-using
DIFFICULTY rather than creating a new opcode.
The probability of randomness output to fall into the range between
2**64 and, thus, to be mixed with PoW difficulty values, is drastically low. Though, proposed threshold might seem to have insufficient distance from difficulty values on Ethereum Mainnet (they are currently around
2**54), it requires a thousand times increase of the hashrate to make this threshold insecure. Such an increase is considered impossible to occur before the upcoming consensus upgrade.
This EIP introduces backward incompatible changes to the execution and validation of EVM state transitions. As written, this EIP utilizes
TRANSITION_POS_BLOCK and is thus tightly coupled with the PoS upgrade introduced in EIP-3675. If this EIP is to be adopted, it MUST be scheduled at the same time as EIP-3675.
Additionally, the changes proposed might be backward incompatible for the following categories of applications:
- Applications that use the value returned by the
DIFFICULTYopcode as the PoW
- Applications with logic that depends on the
DIFFICULTYopcode returning a relatively small number with respect to the full 256-bit size of the field.
The first category is already affected by switching the consensus mechanism to PoS and no additional breaking changes are introduced by this specification.
The second category is comprised of applications that use the return value of the
DIFFICULTY opcode in operations that might cause either overflow or underflow errors. While it is theoretically possible to author an application where a change in the range of possible values this opcode may return could lead to a security vulnerability, the chances of that are negligible.
Testing this functionality goes beyond this document and should be done in a form of integration testing.
RANDOM opcode in the PoS network should be considered as a source of randomness output of a higher strength than the output provided by either the
BLOCKHASH or the
DIFFICULTY opcode in the PoW network.
However, the randomness output returned by the
RANDOM opcode is revealed to the network within the parent block.
Copyright and related rights waived via CC0.
Please cite this document as:
Mikhail Kalinin, Danny Ryan, "EIP-4399: Supplant DIFFICULTY opcode with RANDOM [DRAFT]," Ethereum Improvement Proposals, no. 4399, October 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4399.