Add ERC: Future-block oracleless randomness

ERCS/erc-future-block-randomness.md

@@ -0,0 +1,93 @@
+---
+eip: XXXX
+title: Future-block based oracleless randomness in smart contracts
+description: Practically secure application of blockhashes to derive randomness in smart contracts.
+author: Nik Rykov <[email protected]>
+discussions-to: https://ethereum-magicians.org/
+status: Draft
+type: Standards Track
+category: ERC
+created: 2025-06-16
+license: CC0-1.0
+---
+
+## Abstract
+
+This EIP details a decentralized randomness generation scheme intended for direct implementation within smart contracts. The scheme is designed to mitigate manipulation by block producers by sourcing entropy from a series of future blocks. Its core feature is "entropy slicing," where each 256-bit blockhash is partitioned into 32 distinct 8-bit components. These components are then added to produce a final random value. This partitioning method ensures that the influence of any single block is granular and distributed, significantly increasing the cost, time and difficulty of manipulating the outcome, requiring malicious validator to spend significant resource in case of wanted outcome grinding.
+
+This document serves as a blueprint for developers to implement a robust, on-chain randomness source without introducing external dependencies.
+
+## Motivation
+
+On-chain applications requiring unpredictability, such as games or lotteries, face a fundamental challenge: sources of entropy like `block.timestamp` or `blockhash(block.number)` are controllable by the block producer. A malicious producer can withhold a block if the resulting randomness is unfavorable, an attack known as "grinding."
+
+The primary goals of this scheme are:
+
+1.  **To Distribute Trust:** By sourcing entropy from multiple future blocks, the scheme forces an attacker to control a consecutive sequence of blocks to gain significant influence.
+2.  **To Granularize Influence:** By slicing each blockhash into many small parts, the scheme prevents an attacker from targeting high-value bits in the final output. Control over one block's entropy is fractured into dozens of low-impact components, making grinding favorable MSBs computationally expensive.
+3.  **To Be Self-Contained:** The scheme operates entirely on-chain, eliminating the need for external oracles, their associated trust assumptions, and potential operational costs.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
+The Multi-Block Entropy Slicing scheme is defined by a set of parameters, a state management flow, and a computational algorithm.
+
+### Parameters
+
+Implementations of this scheme should define the following parameters:
+
+-   `BLOCK_WINDOW`: The number of consecutive future blocks used as an entropy source. A recommended value is **16**. A larger window increases security but also increases the delay and gas cost of finalization.
+-   `ENTROPY_SLICES_PER_BLOCK`: The number of uniform slices each blockhash is divided into. A recommended value is **32**, corresponding to byte-sized slices.
+
+### State Management Flow
+
+The scheme follows a three-phase lifecycle for each randomness request.
+
+1.  **Request Phase**:
+    *   An actor initiates a request for a random number.
+    *   The system should record the the block number of the request and a unique `requestId`.
+    *   The `requestId` should be unique and acts as nonce to mix with randomness shards.
+
+2.  **Waiting Period (Liveness Delay)**:
+    *   A mandatory waiting period of `BLOCK_WINDOW` blocks must pass after request's block number.
+    *   During this time, the future blockhashes required for computation are produced by the network. The outcome remains undetermined.
+
+3.  **Finalization Phase**:
+    *   After the waiting period, a function can be called to execute the computation algorithm using the now-available blockhashes.
+
+### Computation Algorithm
+
+The core of the scheme is its two-stage entropy aggregation algorithm. To compute the randomness for a given `requestId` originating from `requestBlockNumber`:
+
+1.  **Initialize**: An accumulator, `randomness_accumulator`, is initialized to zero.
+
+2.  **Aggregate**: The algorithm MUST perform the following loop:
+    *   For each block `i` in the range from `requestBlockNumber + 1` to `requestBlockNumber + BLOCK_WINDOW`:
+        a.  **Source the blockhash**: Fetch the `blockhash(i)`.
+        b.  **Bind to request**: Create a request-specific hash to prevent cross-request contamination: `intermediate_hash = keccak256(abi.encodePacked(blockhash(i), requestId))`.
+        c.  **Slice and Sum**: Treat the 256-bit `intermediate_hash` as an array of `ENTROPY_SLICES_PER_BLOCK` (e.g., 32) slices. Add the numerical value of each slice to `randomness_accumulator`. For 8-bit slices, this means iterating through each of the 32 bytes and adding its `uint8` value to the accumulator.
+
+The final value of `randomness_accumulator` is the resulting random number.
+
+## Rationale
+
+*   **Future Blockhashes as Entropy Source**: Using future blocks is critical. The hashes are not known at the time of the request, forcing a potential attacker to act *after* the request is committed.
+*   **Entropy Slicing as an Anti-Grinding Mechanism**: A simple aggregation (e.g., `keccak256` of all blockhashes) would be vulnerable to an attacker controlling the *last* block in the window, as they could grind that block's hash to manipulate the final outcome. By slicing and summing, the influence of each bit from a single blockhash is significantly diluted. It is computationally infeasible to precisely control the final sum by manipulating one of the 512 additive parts.
+*   **Request-Specific Hashing**: Binding the `requestId` into each `intermediate_hash` ensures that each randomness generation is an isolated process. This prevents scenarios where two requests in the same block could be manipulated simultaneously or produce identical results.
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+## Security Considerations
+
+Implementers of this scheme must be aware of the following security characteristics:
+
+*   **Collusion Threat**: The scheme's security is proportional to the decentralization of block production. A cartel of producers controlling a significant fraction of blocks within the `BLOCK_WINDOW` could collaborate to influence the outcome. The slicing mechanism acts as a strong economic deterrent by making this influence imprecise and costly to coordinate, requiring strong hardware capabilities for efficient grinding, however validators still might have small unfair edge.
+*   **Liveness of `blockhash`**: The `blockhash` opcode can only access the 256 most recent blocks. Any implementation must ensure that finalization occurs before `requestBlockNumber + 256`. Requests not finalized within this period will become unfulfillable.
+*   **Finalization Incentive**: The scheme relies on an external actor to trigger the finalization phase. While this can be the original requester, robust applications should consider incentives for third-party finalization to ensure liveness if the original requester abandons the request.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).