EIP-4399: Supplant DIFFICULTY opcode with RANDOM (#4399)

* EIP-4398: Supplant DIFFICULTY opcode with RANDOM

* eip-4398: rename to 4399

* EIP-4399: provide a link to the discussion thread

EIPS/eip-4399.md

@@ -0,0 +1,110 @@
+---
+eip: 4399
+title: Supplant DIFFICULTY opcode with RANDOM
+author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo)
+discussions-to: https://ethereum-magicians.org/t/eip-4399-supplant-difficulty-opcode-with-random/7368
+status: Draft
+type: Standards Track
+category: Core
+created: 2021-10-30
+requires: 3675
+---
+
+## Abstract
+
+This EIP supplants the semantics of the return value of existing `DIFFICULTY` opcode and renames the opcode to `RANDOM`.
+
+The return value of the `DIFFICULTY` opcode after this change is the output of the randomness beacon provided by the beacon chain.
+
+
+## Motivation
+
+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](./eip-3675.md), 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 `DIFFICULTY` opcode.
+
+
+## Specification
+
+### Definitions
+
+* **`TRANSITION_POS_BLOCK`** The definition of this block can be found in the Definitions section of [EIP-3675](./eip-3675.md#definitions).
+
+### Block structure
+
+Beginning with `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.
+
+### EVM
+
+Beginning with `TRANSITION_POS_BLOCK`, the `DIFFICULTY` opcode, i.e. the EVM instruction with the number `0x44`, **MUST** return the value of the `mixHash` field.
+
+*Note*: The gas cost of the `DIFFICULTY` opcode remains unchanged.
+
+### Renaming
+
+The `mixHash` field **SHOULD** further be renamed to `random`.
+
+The `DIFFICULTY` opcode **SHOULD** further be renamed to `RANDOM`.
+
+
+## Rationale
+
+### Including randomness output in the block header
+
+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.
+
+### Using `mixHash` field instead of `difficulty`
+
+Client software 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, total difficulty computation would become overflow prone if the randomness output supplanted the value of the `difficulty` field.
+
+### Reusing existing field instead of appending a new one
+
+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.
+
+### Reusing the `DIFFICULTY` opcode instead of introducing a new one
+
+See the [Motivation](#motivation).
+
+### Renaming the field and the opcode
+
+The renaming should be done to make the field and the opcode names semantically sound.
+
+
+## Backwards Compatibility
+
+This EIP doesn't introduce any backward incompatible changes to the base protocol. Though, the changes it propose might be backward incompatible for the following categories of applications:
+* Applications that uses the value returned by the `DIFFICULTY` opcode as the PoW `difficulty` parameter
+* Applications which logic depending on the `DIFFICULTY` opcode return value to be relatively small number
+
+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 comprises the applications that use the return value of the `DIFFICULTY` opcode in operations that might cause either overflow or underflow errors. Applications where the result of such errors may turn into security violations are not considered by this EIP.
+
+
+## Test Cases
+
+Testing this functionality goes beyond this document and should be done in a form of integration testing.
+
+
+## Reference Implementation
+
+*TBD*
+
+
+## Security Considerations
+
+The `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 within the parent block.
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).